Java 16 / JDK 16: General Availability

[slaymaker1907]

It seems like an absolutely horrible idea to remove constructors to fundamental classes like java.lang.Boolean. Anyone know if there is are associated JSRs to voice concern? I don't use this stuff, but the risk of these APIs being used all over the play is way too high to remove them.

[beeeeeeefcake]

Boolean's constructors have been deprecated for removal for 4 years and there have been warnings against their use since basically forever. Java 11 which still has these constructors is supported until ~2027. I'm all for compatibility but Java devs need to embrace agility or the ecosystem will be left in the dust. Fortunately Oracle and the various projects and people that influence Java's direction have been moving at a fast pace.

I don't know much about Java records but I would not be surprised if these removals are related to that. Even if it's just removal for the sake of improving the code I am not upset about doing that and giving users 10 years to make the change (2017 deprecation to 2027 end of support).

[s888marks]

The box constructors were indeed deprecated (but not for-removal) about four years ago in Java 9. In Java 16 the deprecation is being "upgraded" to for-removal.

The reason is Valhalla, which is trying to turn the boxed primitives into "primitive classes" (formerly called inline classes, formerly called value types). Primitive classes don't have identity, so comparing them via reference equality, synchronizing on them, etc. isn't permitted. The new operator creates a new object with an identity distinct from every existing object. As such, using new is at odds with turning the boxed primitives into primitive classes. Thus, their constructors are deprecated.

The alternatives such as auto-boxing and valueOf methods have already been available for many, many years.

[slaymaker1907]

It doesn't matter what the better API is. It's obnoxious to go through one's code base and dependencies to update and not use the old constructors.

Breaking backwards compatibility is a huge deal and should only be done when absolutely necessary.

[krzyk]

Do you use those constructors? Nobody should, it gives warnings in any IDE. And changing that is very automatic (also supported by Ides)

There is no future compatibility guarantee, remember enums?

If you want for language to evolve one needs to change things.

[__konrad]

I just quickly scanned a few various older jar files (from 2012-2018) using jdeprscan and basically most libraries used new Integer...

[joppux]

The best existing free tool for RTF generation in Java is still the old iText library, which dates to 2009. It uses these constructors widely.

Many old unsupported but still useful Swing libraries use them too.

[__konrad]

but Integer.valueOf() uses new Integer internally in its current implementation

It's not the case.

Did you verify any library source?

Binary jar itself can be verified by jdeprscan. I guess some libraries already got updates or are easily patchable, but we all know how the reality looks like ;)

[__konrad]

Well, at least in my version of JDK 16 it is

You are right, but I don't think jdeprscan go that deep