You skipped the intended solution:
Integer p = Integer.valueOf(1);
This pattern is known as Factory method pattern. One may ask what the benefit of this method is. Luckily, the implementation of class Integer
is open-source, so let's take a look:
public static Integer valueOf(int i) {
if (i >= IntegerCache.low && i <= IntegerCache.high)
return IntegerCache.cache[i + (-IntegerCache.low)];
return new Integer(i);
}
There seems to be some kind of Integer
-value cache. If one requests an Integer
with a value within the cache-range, Java does not create a new object, but returns a previously created one. This works because Integer
s are immutable. One can even control the upper cache limit with the system property java.lang.Integer.IntegerCache.high=...
.
And why do the other two methods of creating an Integer
generate a warning? Because they were set deprecated with Java 9.
Integer#Integer(int value)
:
Deprecated. It is rarely appropriate to use this constructor. The static factory valueOf(int)
is generally a better choice, as it is likely to yield significantly better space and time performance. [...]
Integer#Integer(String s)
:
Deprecated. It is rarely appropriate to use this constructor. Use parseInt(String)
to convert a string to a int
primitive, or use valueOf(String)
to convert a string to an Integer
object. [...]
And just for completeness, here is the part for Integer.valueOf(int i)
:
Returns an 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. This method will always cache values in the range -128
to 127
, inclusive, and may cache other values outside of this range.
EDIT 1: Thanks to @VGR mentioning that
Integer p = 1;
is equivilant to
Integer p = Integer.valueOf(1);
This, however, is only true for int
-values between -128
and 127
. The behaviour is defined in JLS §5.1.7:
[...] If the value p
being boxed is the result of evaluating a constant expression (§15.28) of type boolean
, char
, short
, int
, or long
, and the result is true
, false
, a character in the range '\u0000'
to '\u007f'
inclusive, or an integer in the range -128
to 127
inclusive, then let a
and b
be the results of any two boxing conversions of p
. It is always the case that a == b
.
EDIT 2: Thanks to @DorianGray, who brought the following to my attention.
While not in the JLS, the version of javac
I am using (9.0.4
) does compile the boxing down to Integer.valueOf(...);
as it is shown in this answer by Adam Rosenfield.