Keeping `new Integer` source compatibility with unnamed factory method
forax at univ-mlv.fr
Wed Nov 4 21:16:36 UTC 2020
----- Mail original -----
> De: "Mateusz Romanowski" <romanowski.mateusz at gmail.com>
> À: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Mercredi 4 Novembre 2020 21:07:35
> Objet: Keeping `new Integer` source compatibility with unnamed factory method
> Hi All,
> regarding the summary of the last EG meeting (2020-11-04) , I can see a
> future me being frustrated with having to keep some dusty `javac` only
> because of some _mature_ code generation tool that "optimizes" by using
You can pro-actively already create a pull request to ask this mature tool to use Integer::valueOf instead of Integer::new.
But you're right that this is a real issue that will hinder the adoption of Valhalla.
> Is the "something special" to keep `Integer::new` source compatibility
> adding an `Integer::new` (and similarly `Object::new`) unnamed factory
> Sorry if I have missed any material discussions related to such an idea.
In the Valhalla world, Integer is not a concrete class anymore but a subtype of int, exactly a subtype of int sees as a primitive object), that why you can not instantiate it directly anymore.
So currently, we are weighting our option more than we are making decision on which backward compatible strategy we want to use, source backward compatible vs binary backward compatible.
So we may still allow to use new Integer()/Integer::new in the source code, to allow any tools that generates Java code to still work but it means that the compiler will have to rewrite it to be Integer.valueOf, which can be very surprising,
new Integer(2) == new Integer(2)
will now return true.
And in that case, we have several ways to do it. We can do that in the library, creating an unnamed factory method that calls Integer.valueOf() as you are suggesting or we can do it directly in the compiler by rewriting all occurrences of new Integer().
> Mateusz Romanowski
More information about the valhalla-dev