Draft JEP: Incubating Language and VM Features

[Remi Forax]

----- Mail original -----
> De: "Alex Buckley" <alex.buckley at oracle.com>
> À: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoyé: Mardi 23 Janvier 2018 00:14:43
> Objet: Re: Draft JEP: Incubating Language and VM Features

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

and the fact that changing the minor version will hinder the adoption of incubating classes in the Java ecosystem.

Let's say I want to use the incubating features, i test with spring and it blows up,
let say i'm a good citizen and i report the issue to the spring bug tracker, what will be the answer ?
  1) ok, let's see all our dependencies where we have the wrong assumption that the classfile version is equivalent to the major version.
  2) it's an incubating class, we do not support them.

and perhaps using Spring is the wrong example, because they are very active in the community, so may be they will come with a patch.
Nevertheless, changing the classfile version semantics goes against the adoption of the very feature you want to promote.

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

yes, right, so we can not use a class attribute, we have to add an ACC_INCUBATOR to flag the class access_flags instead (the other choice i propose in my first email on that subject).

> 
> Any other comments on the JEP?
> 
> Alex

Rémi