Improving compiler messages for preview API

[Joe Darcy]

Hi Jon,

On 8/3/2019 1:57 PM, Jonathan Gibbons wrote:
>
>
> On 6/21/19 10:38 AM, Joe Darcy wrote:
>>
>> PS Prototype version of what this sort of message improvement could 
>> look like, initially coded with a JDK-internal annotation type as 
>> opposed to one in java.lang:
>>
>> http://cr.openjdk.java.net/~darcy/8226585.0/
>>
> Joe,
>
> Could you expand more on the expected use of the "feature" string?
>
>    48     /**
>    49      * Name of the preview feature the annotated API is associated
>    50      * with.
>    51      */
>    52     String feature() default "";
>
>
> Could you maybe give some examples of what feature strings might be, 
> and how you might expect the string to be used, especially in a 
> non-English locale? Would you expect to see any enforcement of the set 
> of permitted strings?
>
>

Hmm. What I had in mind was a way of approximating the feature-specific 
messages javac generates for language features where the feature is named.

So instead of a message like

1629 # 0: symbol, 1: symbol
1630 compiler.note.preview.api=\
1631     {0} in {1} is a preview API and may be removed in a future release

a message closer to

      {0} in {1} is a preview API associated with {2} and may be removed 
in a future release

If the string is not used in the compiler message due to localization 
issues, it might still be informative as part of the javadoc of the 
method, especially if some APIs are less obviously associated with a 
feature than the string method to text blocks.

HTH,

-Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190803/de73a8b1/attachment.html>