RFR 8199194: Add javac support for preview features

[Maurizio Cimadamore]

Thanks - pushed

Maurizio


On 11/04/18 21:11, Jonathan Gibbons wrote:
> +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
>>
>>
>