Improving compiler messages for preview API

[Alex Buckley]

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