Draft JEP: Incubating Language and VM Features

Alex Buckley alex.buckley at oracle.com
Tue Jan 23 20:21:38 UTC 2018

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


More information about the jdk-dev mailing list