Draft JEP: Incubating Language and VM Features (original) (raw)

Alex Buckley alex.buckley at oracle.com
Tue Jan 23 20:59:10 UTC 2018

On 1/23/2018 2:44 AM, Alan Bateman wrote:

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

I understand the scenario, plus there are other enhancements we need to discuss for incubating APIs, to better link them to incubating language and VM features. But let's cross those bridges 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.).

OK.

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?

Maybe, but let's get the JEP submitted first.

Alex

More information about the jdk-dev mailing list