Draft JEP: Incubating Language and VM Features
alex.buckley at oracle.com
Mon Jan 22 19:44:42 UTC 2018
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
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).
More information about the jdk-dev