RFR 8199194: Add javac support for preview features

[Andrey Nazarov]

Line code coverage. Just FYI


—Andrei
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: report.txt
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180413/da3357c4/report-0001.txt>
-------------- next part --------------


> On 12 Apr 2018, at 06:20, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 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
>>> 
>>> 
>> 
>