RFR 8199194: Add javac support for preview features

[Jonathan Gibbons]

+1.

Nice.

-- Jon

On 03/29/2018 10:31 AM, Maurizio Cimadamore wrote:
> 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
>
>