Draft JEP: Incubating Language and VM Features

[Alex Buckley]

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.

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?

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

Alex