Draft JEP: Incubating Language and VM Features (original) (raw)

Remi Forax forax at univ-mlv.fr
Tue Jan 23 08:35:08 UTC 2018

----- 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 minorversion 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 majorversion into a lot of codes. This boils down to saying that we can never use minorversion for anything, because so many stacks assume minorversion 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, superclass might point to a constant pool entry which is not a CONSTANTClassinfo, 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

More information about the jdk-dev mailing list