Draft JEP: Incubating Language and VM Features

[Remi Forax]

Hi Alex,

----- Mail original -----
> De: "Alex Buckley" <alex.buckley at oracle.com>
> À: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoyé: Lundi 22 Janvier 2018 19:50:51
> Objet: Re: Draft JEP: Incubating Language and VM Features

> On 1/20/2018 3:33 PM, forax at univ-mlv.fr wrote:
>> I have used the wrong word, instead of "unknown constant pool
>> attribute", i should have use "unknown constant pool constant".
>> Unknown class/method/field attribute are required to be silently
>> ignored as you point out, but you can not do that for constant pool
>> constant because unlike an attribute which encode its size so you can
>> skip it, a constant pool constant doesn't provide its size only the
>> JVMS provides the association between the kind of a constant pool
>> constant and its size.
> 
> 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.
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.  

> 
> Alex

Rémi