Draft JEP: Incubating Language and VM Features

[Volker Simonis]

Alex Buckley <alex.buckley at oracle.com> schrieb am Di. 23. Jan. 2018 um
00:15:

> On 1/22/2018 2:49 PM, Remi Forax wrote:
> > ----- Mail original -----
> >> De: "Alex Buckley" <alex.buckley at oracle.com> Moving on, it appears
> >> you want to ring-fence the minor_version item. You do not want it
> >> to have a first-class meaning, even in new class files (SE 11 and
> >> greater). Why not?
> >
> > because a lot of bytecode tools provide the version as an int to the
> > applications that used them and not as a pair of major and minor
> > versions, so those applications will break. The fact that the minor
> > version is 0 since a long time is encoded in the assumption that
> > classfile version == classfile major_version into a lot of codes.
>
> This boils down to saying that we can never use minor_version for
> anything, because so many stacks assume minor_version is insignificant.
> OK, your point is clearly made.
>
> I note that class files with incubating content might look very strange
> by ordinary standards. For example, super_class might point to a
> constant pool entry which is not a CONSTANT_Class_info, so there is no
> chance of pre-existing applications understanding a class hierarchy
> naively exposed by the bytecode tool. The protocol between the
> application and the tool would need some adjustment to support the class
> file's expanded definition of "superclass".
>
> Any other comments on the JEP?
>

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).

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.

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.

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!

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?

Regards,
Volker


> Alex
>