Improving compiler messages for preview API

[Jonathan Gibbons]

On 8/9/19 10:28 AM, Alex Buckley wrote:
> On 8/9/2019 7:33 AM, Jonathan Gibbons wrote:
>> We could use a combination of the current deprecation mechanism 
>> combined with a JDK-internal annotation to modify the text of the 
>> warnings generated by javac and the text generated by javadoc.
> ...> In the discussion about having a list of preview APIs, the 
> context was a
>> list hard-coded into the compiler source code. If the list could be 
>> determined "dynamically" at JDK-build time, such as by an annotation 
>> processor, that might be different.
>
> My goal is to move away from terminal deprecation as the mechanism for 
> flagging preview-related APIs in Java SE. Therefore, I do not support 
> the proposal above, which keeps the deprecation mechanism for SE APIs 
> _and_ rigs up a pile of JDK-specific machinery to work as a secondary 
> flagging mechanism for SE APIs and as a new flagging mechanism for 
> non-SE APIs (in the JDK).
>
> It may be that use of reflective Java SE and JDK-supported APIs takes 
> on a bigger role later in 14, as records head towards preview status. 
> (Making no commitments of course!) But my focus at present is use of 
> essential Java SE APIs, because 13 is unfortunately heading out the 
> door with @Deprecated(forRemoval=true) on public methods in java.lang, 
> and that shouldn't happen again.
>
> Alex

Yes, there are clearly two related but somewhat separate discussions 
going on here.

One is the discussion for the evolution of JEP 12: Preview Language and 
VM Features, which I acknowledge has "SE" scope, and which currently 
does not address the issue of incremental evolution of existing APIs, 
and the current recommendation to use incubating APIs is not realistic 
in practice.

The other discussion is if and how to mitigate the impact of JEP 12 on 
JDK APIs and tools, given that JEP 12 is causing an instability in some 
supported JDK APIs. That is a reasonable discussion for those of us 
interested in improving the implementation of our JDK tools to better 
support JEP 12.

-- Jon