Draft JEP: Incubating Language and VM Features

Alex Buckley alex.buckley at oracle.com
Tue Jan 23 20:52:32 UTC 2018

On 1/22/2018 4:46 PM, Volker Simonis wrote:
> 1. You don’t mention long- and short-term realeases in the JEP at all. I
> know you argue that wether a release is long- or a short-term one is a
> vendor and not a standards/specification question - and I can agree with
> that opinion.
> Nevertheless I think it would be strange to introduce an incubating
> feature in a long term release (say Java 11), then refine it in Java 12
> and make it persistent in Java 13. In reality, Java 11 will be supported
> for at least 3 years or more, but 12 and 13 for six month only. So the
> old, deprecated version of the incubating feature from Java 11 will
> probably get a much higher adoption than the final one from Java 12 and
> 13 (at least until the next long term release). I think we can already
> see that adoption of short-term releases is quite low in the industry
> (everybody is waiting for Java 11).

As you say, vendor issues such as support, certification, and training 
are not discussed in the JEP. Your comments are well taken nonetheless.

> Furthermore, while understandable, the claim that a version N+1 isn’t
> allowed to support the incubating feature of version N will even further
> decrease the adoption rate of short term releases if they differ
> incubating feature wise.

If Java SE N+1 chooses to drop a feature that was incubating in Java SE 
N, then presumably there is a reason for that. Maybe the feature 
re-incubates in N+1 and is much more popular and people flock to N+1.

> Finally, the JEP doesn’t specify if version N may (silently or
> explicitly) support version N+1’s incubating features. This may be
> attractive for LTS releases.

If Java SE N had no notion of feature X, and Java SE N+1 introduced X as 
an incubating feature, then there is no realistic possibility of doing a 
Maintenance Release of SE N to add an incubating feature X.

> I don’t know how this dilemma could be solved, but I think in reality it
> will make a significant difference if an incubating feature will be
> introduced in a long- or short-term release.


> 2. You use the example of the ‘_’ character to advertise the incubating
> features as a means to change the Java platform faster (i.e. within the
> course of one instead of two major releases) in a backwards incompatible
> way. Not sure everybody will see that as a desirable feature. Especially
> not if that means within 6 month!

I accept it's not an exciting incubating feature even for people who 
wish the Java language would remove features faster, but it has the 
benefit of mapping directly to something we really did, and in 
timeframes (JDK 8 and 9) that people readily recall. Obviously the 
faster cadence will affect the release of all incubating content 
(incubating APIs in incubator modules as well as incubating language/VM 

> 3. You write that the decision wether an incubating feature should
> become permanent is “left to the judgment and expertise of the Spec.
> Lead of the Java SE Platform”. Shouldn’t that actually be decided by the
> corresponding JSR Expert Group and the JCP EC?

I meant to write "... the Spec Lead of the Umbrella JSR for the Java SE 
$N+1 Platform", who of course takes the decision in consultation with 
the Expert Group of that JSR. Nothing in this JEP should be interpreted 
as changing how Umbrella JSRs go through the JCP.


More information about the jdk-dev mailing list