Improving compiler messages for preview API

[Alex Buckley]

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