JEP 12: Treatment of standard APIs supporting preview features
alex.buckley at oracle.com
Fri Mar 16 21:34:41 UTC 2018
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 .
- The feature was mapped out through 2016, including two large public
- A high-quality implementation  and spec  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  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 . (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
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.
More information about the jdk-dev