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é: Lundi 22 Janvier 2018 20:44:42
> Objet: Re: Draft JEP: Incubating Language and VM Features

> On 1/22/2018 11:21 AM, Remi Forax wrote:
>> ----- Mail original -----
>>> De: "Alex Buckley" <alex.buckley at oracle.com> À: "jdk-dev"
>>> Let's suppose we have a Java SE 11-compliant JVM implementation and
>>> a 55.0 class file. You're saying that a new kind of entry in the
>>> constant pool is a cleaner way to signal the presence of class file
>>> content that's incubating in SE 11 than a non-zero minor_version.
>>> Please explain why because I don't see it.
>>
>> No, i do not propose to mark an experimental class with an unknown
>> constant pool constant.
>>
>> I said that using a class attribute to mark expertimental classes is
>> better because it doesn't change the semantics of the classfile
>> version.
> 
> First, you keep saying experimental but I tried very hard in the JEP to
> distingush incubating features from experimental features. I sent a mail
> about this last week but it seems to have missed the mark again.
> Incubating != experimental.

my bad, sorry for that.

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

By example, take a look to the code of sun.tools.jar.FingerPrint in the jdk,
there is a method:
  public boolean isCompatibleVersion(FingerPrint that) {
      return attrs.version >= that.attrs.version;
  }
it compares two classfile versions without separating the major and the minor versions, this is ok now, it will be a mess if the minor version is used to encode the fact that a class is incubating.

> 
>> But this come with an issue if the experimental feature add
>> a new constant pool constant and the VM doesn't support experimental
>> features, in this peculiar case, i said that throwing an error
>> because the class is invalid because it contains an invalid constant
>> pool constant instead of throwing an error because the VM doesn't
>> support experimental classes is Ok.
> 
> It's not very nice for the user if a JVM implementation sometimes
> rejects unsupported incubating content cleanly (based on detecting the
> attribute) while at other times throwing errors for the
> really-unsupported unsupported incubating content (in the constant pool).

no, it's not nice, but it's the lesser of two evils.

you can be like Don Quixote and fight all those bad codes, because there are really bad codes or you can be a little more pragmatic and recognize that you can not change the minor version, this ship has sailed a long ago. 

> 
> Alex

Rémi