has now be deprecated in favor of
This, I believe is the same for Byte, Short, Long, Float and Double. This may also be the same Boolean and Character classes.
It is very possible that I find this interesting because I'm preparing for the OCA 1Z0-808 exam where there could very well be questions on the objects listed above.
Campbell Ritchie wrote:Do you know why the Integer(int) constructor was deprecated?
If you are asking me, then the answer is maybe. I did not know what Kenneth mentioned before it was posted, so that could be one reason.
However in the official documentation,
They say that it's slow and it was rarely appropriate to use that constructor.
I suspect that there could be other reasons, which I'm not aware of.
When I started, generics and boxing hadn't yet been introduced. I think there were lots of complaints about generics because older languages like Eiffel and C++ supported generics when Java® didn't. The basis for introducing generics was worked out about 1999 but it wan't until Java5 in 2004 that generics were implemented. Before that we had to write things like:-Old Eiffel users will of course remember that Bertrand Meyer was scathing about the absence of generics in Java®. Anyway, 2004 came and 2004 went and it became possible to say that List would only contain Integers. It has never been possible to implement a List<int>.But they introduced boxing at the same time, so we no longer had to write the constructor explicitly:-Now, doesn't that look better
So, let's look at the Java® Language Specification (=JLS). It tells you about boxing, and also that a certain range of values must be cached. So if I box 123 1,000,000,000×, my fingers will fall off and I shall have one Integer instance representing 123. Had I used new Integer(123), I should have 1,000,000,000 different instances. I believe that boxing uses the Integer#valueOf(int) method but I am not certain; you can verify that with the javap tool. If you look up the Integer#valueOf(int) method, you will find it caches values just as does boxing, which means that method is better to use than the constructor. Somewhere on this forum, Rob Spoor said that Cay Horstmann's suggestion for calculating hash codes was horrible because it uses new Integer(int). So there was a widespread feeling that that particular constructor was bad practice. And in more recent editions of his book, Horstmann has used Integer.valueOf(int).
As well as boxing, unboxing was introduced in Java5. I believe that unboxing uses the intValue() method inherited from Number (not certain), which has been available since the first days of Java® for unboxing (that valueOf method was introduced in Java5).
So, we now have a situation where there is a factory method which works better than the constructor. It caches certain values (the range can be increased by the user) and is therefore better than that constructor. If you look in Effective Java by Joshua Bloch or other sources, you will find that factory methods can often be better than public constructors. Look at the classes in the java.time package. Most of them don't have a public constructor. Obviously the developers at Oracle have decided to be assertive and they have now deprecated that constructor in Java9.
And now I have a few minutes to try it out:-
Yesterday, I wrote:. . . you can verify that with the javap tool. . . .
The lines marked 7: and 18: should verify which methods are used; this might change in future versions if new methods are introduced.
javap -c BoxingDemo
If p is a value of type int, then boxing conversion converts p into a reference r of class and type Integer, such that r.intValue() == p
I googled JLS unboxing and I didn't get what I expected.
No, otherwise that would mandate an implementation detail. If ever a more efficient analogue of valueOf is designed, it would be possible to change to use that instead. Let's try with what they had before valueOf was introduced. You can't use boxing but you can use something different.
Paweł Baczyński wrote:. . . the Java Language Specification does not mandate that Integer.valueOf(int) is used. . . .
Without the source flag it defaults to Java8. I must remember to keep an old JDK in case I ever need to go back to JDK1.4.
javac -source 1.4 StringConcatenation.java
warning: [options] bootstrap class path not set in conjunction with -source 1.4
warning: [options] source value 1.4 is obsolete and will be removed in a future release
warning: [options] target value 1.4 is obsolete and will be removed in a future release
warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
javap -c StringConcatenation
You should be able to guess the differences without my having to tell you.
javap -c StringConcatenation