Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p><strong><code>public static Integer valueOf(int i)</code></strong></p> <p>Returns a Integer instance representing the specified int value. If a new Integer instance is not required, this method should generally be used in preference to the constructor Integer(int), as this method is likely to yield significantly better space and time performance by caching frequently requested values.</p> <p>Parameters:<br> <code>i</code> - an int value.<br> Returns:<br> <code>a</code> Integer instance representing <code>i</code>.<br> Since:<br> 1.5</p> </blockquote> <p>refer <a href="http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Integer.html#valueOf%28int%29" rel="nofollow">http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Integer.html#valueOf%28int%29</a></p> <p>This variant of valueOf was added in JDK 5 to Byte, Short, Integer, and Long (it already existed in the trivial case in Boolean since JDK 1.4). All of these are, of course, immutable objects in Java. Used to be that if you needed an Integer object from an int, you’d construct a new Integer. But in JDK 5+, <strong>you should really use valueOf because Integer now caches Integer objects between -128 and 127 and can hand you back the same exact Integer(0) object every time instead of wasting an object construction on a brand new identical Integer object.</strong></p> <pre><code>private static class IntegerCache { private IntegerCache(){} static final Integer cache[] = new Integer[-(-128) + 127 + 1]; static { for(int i = 0; i &lt; cache.length; i++) cache[i] = new Integer(i - 128); } } public static Integer valueOf(int i) { final int offset = 128; if (i &gt;= -128 &amp;&amp; i &lt;= 127) { // must cache return IntegerCache.cache[i + offset]; } return new Integer(i); } </code></pre> <p>refer <a href="http://tech.puredanger.com/2007/02/01/valueof/" rel="nofollow">Why YOU should use Integer.valueOf(int)</a></p> <p><strong>EDIT</strong></p> <p>autoboxing and object creation:</p> <p>The important point we must consider is that autoboxing doesn't reduce object creation, but it reduces code complexity. A good rule of thumb is to use primitive types where there is no need for objects, for two reasons:</p> <p><strong>Primitive types will not be slower than their corresponding wrapper types, and may be a lot faster. There can be some unexpected behavior involving == (compare references) and .equals() (compare values).</strong></p> <p>Normally, when the primitive types are boxed into the wrapper types, the JVM allocates memory and creates a new object. But for some special cases, the JVM reuses the same object.</p> <p>The following is the list of primitives stored as immutable objects:</p> <ul> <li><p>boolean values true and false</p></li> <li><p>All byte values</p></li> <li><p>short values between -128 and 127</p></li> <li><p>int values between -128 and 127</p></li> <li><p>char in the range \u0000 to \u007F</p></li> </ul> <p>refer <a href="http://today.java.net/pub/a/today/2005/03/24/autoboxing.html#performance_issue" rel="nofollow">http://today.java.net/pub/a/today/2005/03/24/autoboxing.html#performance_issue</a></p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload