Improving compiler messages for preview API

[Jonathan Gibbons]

On 8/2/19 6:24 PM, Alex Buckley wrote:
> On 8/2/2019 5:45 PM, Tagir Valeev wrote:
>>  > Maybe a cleaner approach is to make use of a @Preview API an error 
>> in the
>>  > absence of the --enable-preview option. This is putting a lot of 
>> weight on an
>>  > annotation, perhaps too much; but I think it would be safer to 
>> explore this avenue.
>>
>> Completely agree: using a @Preview API should be an error in the 
>> absence of the --enable-preview option. Just like as using a preview 
>> syntax without --enable-preview is an error; not a "non-suppressible 
>> warning and special class file version". I think preview API should 
>> be handled in the same way as preview language features.
>
> I support the policy which Stuart and Tagir have described.
>
> A hard partitioning of the SE API into impermanent elements 
> (everything marked @Preview) and permanent elements (everything else, 
> even if marked @Deprecated!) is consistent with the first goal of JEP 
> 12: "Define a model for partitioning new language and VM features ..."
>
> In effect, a Java compiler without preview features enabled will 
> produce a compile-time error for any use of an @Preview program 
> element if it would produce a removal warning for the same use of the 
> element if it were @Deprecated(forRemoval=true) rather than @Preview 
> (and assuming that none of the "unless..." clauses in JLS 9.6.4.6 apply).
>
> Alex

Alex,

One topic for discussion is the interaction with the javac --release 
option. For older releases, you can't use --enable-preview, so I guess 
the behavior follows from that; for the current release, is there any 
reason to allow or restrict the combination with --enable-preview?

-- Jon