Draft JEP: Incubating Language and VM Features

[forax at univ-mlv.fr]

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Rémi Forax" <forax at univ-mlv.fr>
> Cc: "Alex Buckley" <alex.buckley at oracle.com>, "jdk-dev"
> <jdk-dev at openjdk.java.net>
> Envoyé: Samedi 20 Janvier 2018 01:24:03
> Objet: Re: Draft JEP: Incubating Language and VM Features

> On Jan 19, 2018, at 3:39 PM, Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> So let's all agree that this is nice JEP and that the way to mark a class
>> experimental is to add an attribute Experimental to the classfile.

> Remi, you are glossing over a big point here: We are going to be experimenting
> with constant pool formats. You can't read the access_flags or any attributes
> until you have parsed the constant pool.

Ok, better explanation that no access_flags left. 

But the classfile format has been designed to be extensible, which means that even if a VM doesn't know a constant pool attribute, it knows that this is an unknown constant pool attribute because the attribute tag is unknown, so a VM doesn't support experimental features will reject the classfile. 

A VM that doesn't support experimental features doesn't have to support new constant pool attributes while parsing the constant pool, it just have to reject the class because it doesn't support it which is already mandated by the current vm spec. 

> It is unreasonable to parse the constant
> pool before you know whether it is allowed to have experimental features in it.

I disagree, for a VM that support experimental features, i find it reasonable to parse the constant pool with the new attributes given that if the class is not marked as experimental, an error will be thrown. 
it's just a belt and braces approach. You do not have to just support the constant pool attribute, you also have to have the class attribute Experimental. 

> This leaves the magic number, major and minor versions, and the CP length
> itself as channels to carry the experimental bit. Of those, the most reasonable
> and intuitive is the minor version.

if you put yourself in a corner, then changing the minor version is the best you can do, but you do not have to go to that corner in the first place. 

The classfile format has been designed to be extensible, we should rely on it. 

> So it's the minor version. Next question: What bit pattern? Best answer,
> AFAIK is to reserve one bit and concentrate on that. That leaves the other
> minor version bits untouched and free for other uses.

> Next question: Does anybody actually *use* the minor version bits? The
> spec suggests they were in play once, but I have *never* seen anybody use
> them to carry information in modern versions of Java. If those 16 bits are
> always zero, then clearly we can steal one of them. And I think we have
> both the habit and the right of declaring that they must be zero and are
> reserved for future extensions, such as an experimental flag.

Changing the semantics of minor_version has a high cost, mostly because major_version and minor_version are seen as one unique integer, so changing the semantics of the minor_version implies changing the semantics of the classfile version. 

> — John

Rémi 

> P.S. In fact (separate conversation) I would like to reserve *another* minor
> version bit to denote "private use plane", meaning that projects like
> Valhalla can mark their prototype classfiles using the minor version
> in such a way that there is guaranteed to be never any standard JVM
> that will ever load those prototype classfiles.