Draft JEP: Incubating Language and VM Features
Alan.Bateman at oracle.com
Tue Jan 23 10:44:23 UTC 2018
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?
More information about the jdk-dev