Draft JEP: Incubating Language and VM Features (original) (raw)
Jonathan Gibbons jonathan.gibbons at oracle.com
Mon Jan 22 20:14:40 UTC 2018
- Previous message: Draft JEP: Incubating Language and VM Features
- Next message: Draft JEP: Incubating Language and VM Features
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Whilst I support the use of the minor_version field as proposed, with this proposed bit, and the additional bit proposed by John Rose earlier in this thread, the value is trending away from being a "minor version number" and towards being "version flags".
-- Jon
On 1/22/18 11:44 AM, Alex Buckley wrote:
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 minorversion. 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 minorversion 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
- Previous message: Draft JEP: Incubating Language and VM Features
- Next message: Draft JEP: Incubating Language and VM Features
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]