Rename "incubating" language/VM features to "preview"
alex.buckley at oracle.com
Tue Feb 27 20:51:11 UTC 2018
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 , 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  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
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
 Setting aside an obscure flag to `jmod`.
More information about the jdk-dev