RFR 8199194: Add javac support for preview features
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Thu Mar 29 17:31:33 UTC 2018
Hi,
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)
http://cr.openjdk.java.net/~mcimadamore/8199194/
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.
Cheers
Maurizio
[1] - http://openjdk.java.net/jeps/12
[2] - https://bugs.openjdk.java.net/browse/JDK-8200312
More information about the compiler-dev
mailing list