JEP 12: Treatment of standard APIs supporting preview features

[Alex Buckley]

On 3/5/2018 3:25 PM, Stephen Colebourne wrote:
> Previewing APIs or language features seems great at first glance. We
> get to play with new stuff before final release. However, I am
> concerned that mandating these as part of the SE specification is
> entirely the wrong way to go. By mandating it, the effect is to
> require other JVM/JDK/IDE/Tool teams to commit to potentially
> considerable amounts of work for features that may yet change
> radically. This is highly undesirable and totally unrealistic IMO,
> especially given the strain a 6 month cadence is already going to
> place on some of these teams.

JEP 12 goes to great lengths to communicate that a preview feature 
should only be included in the Java SE Platform if it's 99% done. While 
no-one can predict the future, the owner of a feature JEP is exhorted to 
count the costs of the feature being previewed then removed, which is 
the same as "change radically".

> The primary goal of JEP 12 is broader testing/experimentation of the
> feature, but this has always been difficult to obtain, and I'm
> unconvinced that bundling the feature in the main JDK binary makes
> that much difference (very few people try RC versions of open source
> projects, even though they are easily accessed in Maven central for
> example). And for language changes, most of the time developers have
> to use basic tools anyway, as the tool chain simply will not be
> updated early enough for the meaningful feedback that is desired.

I understand these concerns, but let me try to assuage them with a 
practical example of how a preview feature would have worked:

- JEP 286, Local Variable Type Inference, was created March 2016.

- A prototype implementation was available immediately [1].

- The feature was mapped out through 2016, including two large public 
surveys [2].

- A high-quality implementation [3] and spec [4] were available in March 
2017 (though that date was dominated by Amber's spin up -- treat them as 
being available two months earlier).

- LVTI was, by any measure, stable and complete by mid 2017. It would 
have been a perfect preview feature for JDK 9. Assume it was...

- Observations like [5] would have started trickling in from various 
sources. (Don't underestimate how many tens of thousands of people 
download GA releases *immediately*.)

- People would have written about the preview feature in their articles 
on "What's new in JDK 9 apart from modules". Presentations would show 
it. Tutorials would show it in jshell. Arguments would break out on 
/r/java and /r/programming. (You can believe we follow all this; our 
ivory tower has a great view. (Joke!))

- A six month clock would be running for IDE vendors to finish 
integrating the feature [6]. (Note, finish, not start! They should have 
started months earlier, when the JEP would have been targeted to JDK 9.)

- We'd be heading into JDK 10 GA with an even better feeling about 'var' 
than we have today. Our developer guide would be deeper. The examples 
would be better.

I'm pretty certain that things would play out like this. Language 
features take a year or two to work out, and we wouldn't dream of 
previewing them before that effort has had a good run. Then, previewing 
in GA is basically a guarantee of feedback. I am unconcerned about 
tumbleweeds and silence when it comes to a new Java language feature for 
which opinions are EXPRESSLY requested. If anything, the problem will be 
too much feedback, not too little!

In contrast, putting 'var' in a JDK 9 EA circa late-2016, when 
everything ELSE was still in development, would get little response. 
Prior to GA, you can't see the trees for the trees, let alone see the 
forest.

I can think of at least one feature being discussed on amber-dev today 
which would have been great to preview in JDK 10, if we'd had the ability.

Alex

[1] 
http://mail.openjdk.java.net/pipermail/platform-jep-discuss/2016-March/000038.html
[2] 
http://mail.openjdk.java.net/pipermail/platform-jep-discuss/2016-December/000066.html
[3] http://mail.openjdk.java.net/pipermail/amber-dev/2017-March/000019.html
[4] 
http://mail.openjdk.java.net/pipermail/amber-spec-experts/2017-March/000015.html
[5] 
http://mail.openjdk.java.net/pipermail/amber-spec-experts/2017-November/000146.html
[6] 
http://mail.openjdk.java.net/pipermail/amber-dev/2017-September/002150.html