Draft JEP: Incubating Language and VM Features

[Alex Buckley]

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

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