Rename "incubating" language/VM features to "preview"

[Alex Buckley]

Members of the Expert Group for JSR 384 (Java SE 11) have indicated to 
the Spec Lead that they support the goal of releasing non-final 
language/VM features in order to gain developer feedback, but also feel 
that the "incubating" terminology is too confusing.

I have some sympathy with this. We were initially guided by the 
principles and terminology of incubating APIs [1], but there have turned 
out to be significant differences between incubating APIs (delivered in 
incubator modules) and incubating language/VM features (delivered in 
Java compilers and JVM implementations) :-

1. Incubating APIs are specific to OpenJDK-derived implementations, 
while incubating language/VM features exist in all Java SE implementations.

2. Incubating APIs are "just" APIs in pre-defined namespaces; they 
receive neither support from JDK tools [2] nor acknowledgement in the 
JLS and JVMS. In contrast, incubating language/VM features need support 
from high-profile JDK tools (`javac`, the `java` launcher, `javadoc`, 
`jshell`) and are specified fully in the JLS and JVMS.

3. A non-trivial number of people interpret "incubating" as "not fully 
baked", or as "experimental". These interpretations might sometimes be 
appropriate for incubating APIs, but they are never appropriate for 
incubating language/VM features intended to be 99% stable and complete.

Consequently, some renaming is in order. We like "preview language/VM 
features" for a number of reasons:

- "Preview" is a common, simple word. No compound phrasing 
("early-access") or negative emphasis ("non-final").

- Instead of focusing on where a feature is at the moment ("incubating 
in Java SE $N"), it focuses on where the feature is going ("a preview of 
what will be final in Java SE $N+1"). The sense of forthcoming is strong.

- It makes for a nice hierarchy of language/VM features:
   - Production (Specified and final)
   - Preview (Specified and not final)
   - Experimental (Not specified)

A wrinkle arises in the notional command-line flag offered by JDK 11. 
Simply renaming it from:

   javac --incubating 11 Foo.java

to:

   javac --preview 11 Foo.java

is confusing: if you're compiling on JDK 11, how can you also be 
previewing 11? This goes double if you habitually specify --release 11 
to demand the Java SE 11 source language + class file version + API.

We are reluctant to allow this:

   javac --preview 12 Foo.java

because we do NOT commit to Java SE 12 containing exactly the feature 
previewed in Java SE 11.

We propose dropping the operand to --preview, and then to maintain 
clarity, allowing preview features only when --release is specified :-

   javac --release 11 --enable-preview Foo.java  // OK
   javac --enable-preview Foo.java               // Not OK

Alex

[1] http://openjdk.java.net/jeps/11
[2] Setting aside an obscure flag to `jmod`.