Draft JEP: Incubating Language and VM Features

[Volker Simonis]

On Tue, Jan 23, 2018 at 9:52 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> 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 meant to do this in a "Maintenance Release of SE N". The
question was if a Java vendor can do that in his implementation of
"Java N" if that implementation still passes the "Java N TCK".

As an example take LVTI (JEP 286) which will come in Java 10. Can I
support that in my Java 9 VM ? I'm pretty sure I will pass all the TCK
9 tests even if I don't hide the feature behind a flag, because TCK N
can not realistically test that a Java N implementation doesn't
support N+1 features (because at the time TCK N was written, the
feature in question may have not even existed).

For features which extend the public API, that's a little different,
because the TCK does test that Java N only exports the Java N public
APIs and nothing more. But I could still support new N+1 features and
hide them behind a flag which I don't use during certification. I
could even use the "--incubating" flag for that purpose, because from
my understanding the flag is just mentioned as an example in the JEP
and will not be part of the Java SE standard.

Would such an approach be acceptable?

>> 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.
>
>
> Understood.
>
>> 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 features).
>
>> 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.
>
> Alex