Draft JEP: Incubating Language and VM Features

[Remi Forax]

----- Mail original -----
> De: "Alex Buckley" <alex.buckley at oracle.com>
> À: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoyé: Mardi 23 Janvier 2018 21:21:38
> Objet: Re: Draft JEP: Incubating Language and VM Features

> On 1/23/2018 12:35 AM, Remi Forax wrote:
>> Let's say I want to use the incubating features, i test with spring
>> and it blows up, let say i'm a good citizen and i report the issue to
>> the spring bug tracker, what will be the answer ? 1) ok, let's see
>> all our dependencies where we have the wrong assumption that the
>> classfile version is equivalent to the major version. 2) it's an
>> incubating class, we do not support them.
>>
>> and perhaps using Spring is the wrong example, because they are very
>> active in the community, so may be they will come with a patch.
>> Nevertheless, changing the classfile version semantics goes against
>> the adoption of the very feature you want to promote.
> 
> It's not a goal that Spring (or more likely, the bytecode tools that
> Spring uses) can instantly understand class files which contain
> incubating content.

If you change the minor version, you do not need to only update the bytecode tool but also modify the classes of Spring that uses the bytecode tool.

> Adoption will not be free. For example, the
> incubating content might be a (previously unused) bit in
> ClassFile.access_flags that signifies "This is a data class, so the VM
> should generate equals/hashCode methods under circumstances X and Y ...
> oh, and super_class need not point to a CONSTANT_Class_info." As we said
> earlier, the application (Spring) will have to be fixed to handle the
> novel classes it now sees being returned from bytecode tools. The 0xffff
> minor_version is just the canary in the coalmine -- a ClassFile with
> major.minor 55.0 and ACC_INCUBATOR lurking in access_flags is just as
> much trouble for pre-11 frameworks/tools as a ClassFile with 55.0xffff.
> Ultimately, none of these signals can guarantee that incubating classes
> are treated right by every application and tool, so we'll use the simple
> and direct mechanism of minor_version.
> 
> I'll clarify in the JEP that the reason why ClassFile.access_flags is
> not used to signal incubation is because the joint set of flags in
> ClassFile/field_info/method_info is (i) already very busy (_every_
> bitmask is already allocated to some flag) and (ii) should be reserved
> for actual class/field/method properties rather than the "meta" property
> of incubation.
> 
> Alex

Anyway, i think that changing the minor version is not the best choice but i do not think it's necessary to discuss more on the classfile representation of this feature, let's move on :)

Rémi