Call for feedback -- enhanced switch

forax at univ-mlv.fr forax at univ-mlv.fr
Sat Mar 23 17:56:34 UTC 2019


----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-dev" <amber-dev at openjdk.java.net>, "Alex Buckley" <alex.buckley at oracle.com>
> Envoyé: Samedi 23 Mars 2019 18:40:59
> Objet: Re: Call for feedback -- enhanced switch

>> BTW, it remember me something i have forgotten to ask, for both ecj and javac,
>> when you compile with --enable-preview, all the classes have they minor version
>> changed even the one that doesn't use the switch expression. I've tried to find
>> where this behaviour was documented in the JEP 12 [2] but the "compile-time"
>> section is not clear about that.
> 
> That's correct.  This is not unlike compiling with -source/-target N;
> even if it doesn't use any features added in N, it writes out that
> version of the classfile.  This is predictable for users and way simpler
> for compilers.  The alternative is getting into an interpretation of
> "could this classfile run on a different version", whose
> complexity/benefit ratio would be way out of balance.

There is also a balance between normal users that should not be able to use a preview feature by error if it's too easy to use and early adopters that will not use preview features because it's too cumbersome to use (because in that case there is no point to have a preview mechanism).

In this particular case, it raises the bar to test the feature because you can not just add a dynamic check saying if the Runtime.version() is JDK-12 then calls that method, something early adapters are used too. So i don't disagree with you but i'm afraid that given the few feedbacks we get, we may have to reconsider how users interact with a preview feature. 

regards,
Rémi


More information about the amber-dev mailing list