RFR 8199194: Add javac support for preview features

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu Mar 29 17:31:33 UTC 2018

Here's a langtools patch to support preview language features as 
described in JEP 12 [1]. There's also a pending CSR [2] request that 
describes the set of changes introduced by this patch in great details.

Webrev can be found here (the webrev contains also a preview of the new 
diagnostics emitted by javac, for a quicker evaluation)


Implementation-wise, the main decision was how to model preview support. 
Should it be an extra source (and target) level? I tried to go there, as 
it seems the path of least resistance, but was ultimately too messy. The 
main problem we face is that both Source and Target are enums - 
completely static entities; so we can't attach a lot of state to them 
(which is needed to generate some of the diagnostics required by the 
JEP). At the same time, that seems to break an important invariant, that 
all Source/Target versions should have a corresponding flag that can be 
passed to the -source/--release options. That is, if 'preview' is an 
hidden source level, javac has to start distinguishing about public 
levels and private ones.

Instead, I came up with a different approach - there is a new Preview 
class in langtools, which acts as a 'coordinator' for the preview 
feature. This means that usages of preview features are reported through 
this Preview class by other javac classes. Thanks to this, we now can 
collect all uses of preview features in a single place, and generate 
diagnostics accordingly.

The mapping of which features are preview features is completely ad-hoc, 
which I think it's desirable. We could add a 'preview' token to 
Source.Feature - but I think it's best to ask Preview directly if a 
given Feature is preview or not. This has some advantages:

* when a feature goes from preview to stable, we only need to remove the 
mapping from Preview - Source stays as is
* we can exploit the indirection to support test flavors which treat 
every feature as 'preview'. I used this extensively to be able to 
generate diagnostic tests.

Diagnostic-wise, using preview features with --enable-preview, will 
generate a note similar to the one for unchecked warnings; users can 
recompile with the -Xlint:preview flag to get more detailed messages 
about preview feature usages. Note that by usages here I also mean 
attempts to load classfiles which have the minor version set to the 
special preview value (hence, some changes to ClassReader were needed).

To demonstrate how the preview support could be leveraged, I tweaked the 
methods in JavacParser::checkSourceLevel and 
JavaTokenizer::checkSourceLevel - if the feature to be checked is a 
preview feature (this test can be forced using the -XDforcePreview 
flag), then extra checks are carried out, to make sure that preview 
support is indeed enabled.

Since the set of preview features is currently empty, this patch should 
result in no observable change in the behavior of the javac compiler.


[1] - http://openjdk.java.net/jeps/12
[2] - https://bugs.openjdk.java.net/browse/JDK-8200312

More information about the compiler-dev mailing list