Migrating the primitive boxes to values
forax at univ-mlv.fr
Sat Jan 26 12:22:23 UTC 2019
----- Mail original -----
> De: "Ryan Schmitt" <rschmitt at pobox.com>
> À: "Valhalla Expert Group Observers" <valhalla-spec-observers at openjdk.java.net>
> Envoyé: Vendredi 25 Janvier 2019 23:57:32
> Objet: Re: Migrating the primitive boxes to values
> Is there data to suggest that this breakage would be more painful than,
> say, the removal of sun.misc.BASE64Encoder? (Assuming that's even a
> relevant comparison.)
you have two different effects,
1) == starts to returns true where it was returning false previously
2) synchronized on an Integer throws IllegalMonitorStateException
For (1), we hope it's a minor issue because changing the size of the Integer cache (setting the AutoBoxCacheMax VM option in early JDKs or changing the property java.lang.Integer.IntegerCache.high) as the same side effect.
For (2), at runtime, you have the same kind of effect, get an exception but it's a runtime exception and not an error.
Here again, we expect that it's not a real issue because changing the size of the Integer cache change the behavior of synchronized so the code is already broken.
But given a runtime exception is thrown a some people love to write catch(Exception), you can have programs that run errand instead of stopping to work.
In both case, the program may behave in a strange way when the JDK is updated, which is worst than throwing an error saying that BASE64Encoder is not available.
Also, doing a static analysis of the code to find (1) and (2) is hard, because an Integer can be typed as an Object so you need to do an inter-procedural data flow analysis on the whole code (something that you may never able to do because the notion of "whole code" is fuzzy because of Java dynamic class loading). So detecting bad behavior will be harder than just running jdeps --jdk-internals on your jars.
So compared to the removal of BASE64Encoder, it's better because for most of the existing codes, you don't have to do anything, it will just work, but for a small subset of all existing programs, they will start to behave weirdly because they rely on a broken semantics but were lucky? to work.
> On Fri, Jan 25, 2019 at 10:15 AM Brian Goetz <brian.goetz at oracle.com>
>> Which brings me to my real point: if we go the latter route, when a big
>> legacy customer with a big legacy codebase has their code broken by
>> this, what happens next? I know its really easy to say that we'll tell
>> them they were making a mistake for 22 years and their bad behavior
>> finally caught up with them, but this answer is rarely well received in
More information about the valhalla-spec-observers