Is it valuable for using Integer i = NumberUtils.INTEGER_ONE instead of Integer i = 1? I don't know what happen behind auto boxing.
Thanks
Basically it will be compiled into:
Integer i = Integer.valueOf(NumberUtils.INTEGER_ONE);
assuming INTEGER_ONE is declared as an int.
At execution time, assuming INTEGER_ONE has the value 1, that will actually return a reference to the same object each time, guaranteed by the Java Language Specification, because it's in the range -128 to 127. Values outside that range can return references to the same object, but don't have to.
Many wrappers and utility classes in java have cached pools. Integer uses an internally cached static array of 'Integer' references to dish out when the valueOf() method is invoked. Strings also have a similar pool.
If however you do something like Integer i = 128, that will begin to impact performance since autoboxing will kick in for uncached integers (Not that it does not kick in for cached integers). Unlike the case where cached integers were returned, this statement creates a new object. Object creation is expensive and drags down performance.
[EDIT]
Clarified answer
Related
One new feature of Java 9 is to deprecate the constructor of wrapper objects. The only way to create new Wrapper objects is to use their valueOf() static methods.
For example for Integer objects, Integer.valueOf implements a cache for the values between -128 and 127 and returns the same reference every time you call it.
As API for Integer class says "The static factory valueOf(int) is generally a better choice, as it is likely to yield significantly better space and time performance." and JLS says "Given a value of the corresponding primitive type, it is generally unnecessary to construct new instances of these box classes. The recommended alternatives to construction are autoboxing or the valueOf static factory methods. In most cases, autoboxing will work, so an expression whose type is a primitive can be used in locations where a box class is required"
But what happens with the values outside this range?
For example Integer x = Integer.valueOf(456) is a new object every time the class was executed?
Both
Integer x = Integer.valueOf(456);
and
Integer x = 456;
will always result in a new instance of Integer being created, since 456 is outside the range of the Integer cache.
You can test it by writing
Integer x1 = Integer.valueOf(456);
Integer x2 = Integer.valueOf(456);
System.out.println(x1==x2);
which will print false.
First why bother with these details - the correct way to compare Integer objects is to use either:
if (x.intValue() == y.intValue()) or better x.equals(y)
Don't rely on the fact that there is a cache under any circumstances, since this cache's upper bound can be changed as a property, you can see it via:
java -XX:+PrintFlagsFinal | grep AutoBoxCacheMax
I know in Java, there are three different ways below to transform the primitive types to their corresponding wrapper classes. However, is there any preferred way if performance is critical ?
Integer i = new Integer(5);
Integer i = 5;
Integer i = Integer.valueOf(5);
The javadocs for Integer.valueOf(int) emit a pretty clear recommendation:
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.
And as pointed out by Pshemo in the comments, and as considered in this SO thread, Integer i = 5; essentially gets converted automatically to Integer i = Integer.valueOf(5);. So using either won't make a difference performance-wise.
So if performance is a concern, simply avoid using new Integer(5) to benefit from the caching.
Read this on the oracle docs java.lang page:
Frequently it is necessary to represent a value of primitive type as if it were an object. The wrapper classes Boolean, Character, Integer, Long, Float, and Double serve this purpose.
I'm not sure I understand why these are needed. It says they have useful functions such as equals(). But if I can do (a==b), why would I ever want to declare them as Integer, use more memory and use equals()? How does the memory usage differ for the 2?
Java's generics system only supports class types. And since primitives are not classes, they can't be used with generics. However, a primitive's wrapper class can be used as a generic type. For example, you may not declare an ArrayList<int>, but you can achieve a similar functionality with an ArrayList<Integer>.
It is also of occasional use to initialize a variable's value to null. Primitives, however, cannot be set to null; that privilege is reserved for objects.
// This is OK
Integer iDontKnowValueYet = null;
// Compile error!
int iDontKnowThisYetEither = null;
Things like int, char, double are all primitives meaning they do not need to be instantiated by using "new". Things like Integer, Character, Double are objects that take up more room on the computer (since there is more overhead for objects) but you can use methods like Integer.parse(). In general, use the primitives and only use the object versions if you need one of the methods.
To answer the thing about a==b vs a.equals(b):
Integer a = new Integer(5);
Integer b = new Integer(5);
Even though they are the same value (which is what .equals tests for) they are not the same piece of memory since you said "new" twice. a!=b but a.equals(b)
Integer a = new Integer(5);
Integer b = a;
Now they use the same piece of memory meaning if you change one, you change them both (unless you use "new" again). a==b and a.equals(b)
//using last code block
b = new Integer(5);
Now once again a!=b but a.equals(b)==true since once again they have the same value but they are on different pieces of memory.
Your ints are usually wrapped in wrapper classes when you put them in a data structure. So, .equals method is used to determine when you call .contains method on the data structure.
Other usefule methods:
toString
toHexString
parseString
Besides the syntax, is there a difference (performance, semantics, etc.) between these two ways to initialize Integers?
Integer i = new Integer(10);
Integer i = Integer.valueOf(10);
And is there a difference between these two ways to compare an Integer for equality against a constant?
i.equals(CONSTANT);
(CONSTANT).equals(i);
new Integer(10) creates a new integer object.
Integer.valueOf(10) may potentially return an interned instance of the object. Java keeps a pool of freqeuently used integers (generally) the small ones.
i.equals(CONSTANT) and CONSTANT.equals(i) differ in behaviour only when i is null. I prefer the second form since it's more null safe.
new Integer(10) will always create a new Integer object with the value 10.
Integer.valueOf(10) will return a Integer object with the value 10 from a pool (the pool only contains a limited range of values, numbers outside of this pool will return a new Integer object as well).
i.equals(CONSTANT) will throw a NullPointerException when i is null.
CONSTANT.equals(i) will never throw a NullPointerException (assuming CONSTANT is a non-null static final field and its equals() method is sane).
As Java Doc for Integer.valueOf says,
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.
Parameters:
i an int value.
Returns:
a Integer instance representing i.
Since:
1.5
Integer.valueOf(int) has better performance because it caches values between -128 and 127.
Nothing, except when i is null. The latter should be used to deal with this case instead of having an extraneous if check.
This link explains the first.
CONSTANT.equals(i) will not throw NUllPointerExcpetion obviously unless CONSTANT is null.
What is the reason why Wrapper classes (like Integer, Double, etc.) don't have a setter for their inner primitive value ?
I am asking this because that kind of functionality would have simplified calculus, and have made the Java language a little more flexible .
Let me give you some examples.
1) Let's take the following example:
Integer x = new Integer(5);
x++;
The previous code behind the scenes is performing autoboxing . Something like:
int x_tmp = x.intValue();
x_tmp++;
x = new Integer(x_tmp); // Yes that's a new memory allocation
Because of this problem doing calculus on Wrapper is slower than performing on plain primitive types. With a setter it would've been more easy to increment the inner value, without allocating another object on the heap.
2) Another issue that is bugging me is that is impossible in Java to write a swap function like I can do in C (using pointers) or in C++ (pointers or references).
If i write void swap(Integer x, Integer y) I cannot acces the inner value because, and It is going to be impossible for me to swap the values.
PS:
A friend of mine suggested that i should consider the bigger picture, and think in terms of concurrency and type immutability.
So do you have an explanation for this ?
Thanks!
Wrapper classes are usually not used unless you need to put them into a collection. If they were mutable it would make problems if used inside sets and as keys for hashtables.
Sets and hashtables need the hash value to be always the same.
1) With a setter, the wrapper types would be mutable. Immutability is a good thing in many ways... threading, general understandability of the code etc. Personally I think it's a shame that Calendar and Date are mutable, for example.
In fact, your expansion of x++; isn't quite right - it uses Integer.valueOf which doesn't always create a new value. For example:
Integer x = 5;
x++;
Integer y = 5;
y++;
// This prints true
System.out.println(x == y); // Compare references
Only a limited range of Integer values are cached like this (the spec defines what values must behave this way, but allows for a wider range if the JRE wishes to do so)... but it does mean that it won't always be creating a new object.
2) Yes, Java doesn't have pass by reference. Frankly I very rarely find that to be a problem. How often do you really need to swap the values of variables?
Caching Integers in the range from -128 to 127 requires immutable Integers. Consider the follwoing code:
Integer id = Integer.valueOf(1); // a new Integer, cached in Integer class
// and somewhere else
Integer key = Integer.valueOf(1); // returns the cached value
Now if Integer was mutable and had a setter and someone did
key.setValue(2); // not legal Java code, just for demonstration
this would change the value of id too and, to a lot of peoples surprise:
Integer one = Integer.valueOf(1);
if (one != 1)
System.out.println("Surprise! I know, you expected `1`, but ...");
In Java, Strings and wrapper classes are designed as immutable to avoid accidental changes to the data. You can check the below article for further information.
Why Strings and Wrapper classes are immutable in java?