Call for feedback -- enhanced switch

[Jorn Vernee]

> I'm afraid that given the few
> feedbacks we get, we may have to reconsider how users interact with a
> preview feature.

I think for most people it's copying something they see online into 
their IDE, and if they can't get it working within an hour they give up 
and go do something else.

IntelliJ & Eclipse support switch expressions, but not out of the box 
(AFAICT IntelliJ also requires an early access version). There are other 
problems with tooling as well (recent e.g. 
https://stackoverflow.com/q/55303837). Setting the javac & VM flags on 
the command line is easy enough, but I'm proposing that this is not the 
typical usage mode.

I think it just takes time for tooling to catch up with the 
language/compiler changes before the general public feels that it's 
'easy enough' to try out these new features on their code bases. I think 
for enhanced switch we're only just starting to get to that point. 
Looking at the questions coming up on Stack Overflow tagged with java-12 
[1], with half the questions asked in the last week (out of 15), people 
are only just starting to use Java 12 at all.

So, as far as I can tell, it's still 'early days'.

Jorn

[1] : https://stackoverflow.com/questions/tagged/java-12

forax at univ-mlv.fr schreef op 2019-03-23 18:56:
> ----- 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