Draft JEP: Incubating Language and VM Features

[Alan Bateman]

On 22/01/2018 23:14, Alex Buckley wrote:
> :
>
> Any other comments on the JEP?
It looks very good. A few comments/questions:

The case where an incubating language or VM feature relies on (or 
"associated informally with") an incubating API is clear - the VM must 
resolve the module with the API that the feature depends on (the 
jdk.incubator.strings module and its classfile package is a good 
example). The other direction, where an incubating module contains code 
that relies on an incubating language or VM feature isn't as clear - are 
all bits in the minor_version field of the module-info.class all set or 
maybe the JDK-specific ModuleResolution attribute has a flag to indicate 
that it needs the VM to run with support for incubating VM features 
enabled? I'm asking because there it wouldn't be hard to check the 
mismatch at startup o avoid a CFE some time later.

The "Run time" shows the java launcher taking a flag to enable the 
support. A detail for this section is that it will likely be a VM option 
rather than a java launcher option (users of the java launcher will not 
see the difference). This is because every VM is required to support a 
way to enable incubating VM features so it has to be enabled when 
creating the VM (JNI CreateJavaVM etc.).

The JEP is SE scope but I assume a few JDK or OpenJDK topics will come 
up. Are jtreg enhancements useful to support compiling and running 
tests? Do we want jlink to support including modules that depend on 
incubating VM features?

-Alan