Preview APIs for preview features -- JDK 14+

[Alan Bateman]

On 05/08/2019 12:11, Alex Buckley wrote:
>
> Correct. This proposal is about strengthening the developer's 
> awareness of incautious usage of associated APIs, by strengthening the 
> compile-time story from a removal warning to an error. At run time, we 
> do NOT propose to reject a class file referencing String::stripIndent 
> when preview features are disabled; the checking would be heavyweight 
> and could never account for reflective use. Again, the goal here is 
> developer awareness when they read javadoc and write code.
This make sense. For developers working on the JDK itself there will 
likely be cases in the future where methods associated with a preview 
feature need to be used, maybe an existing method expands its behavior 
when preview features are enabled. We can deal with those using 
reflection or method handles as needed.

One thing that isn't clear from the write-up is whether the APIs will 
have both @Deprecated(forRemoval=true) and @PreviewFeature. I assume 
not, esp. if the standard doclet will highlight the method as it does 
with deprecated methods today. IDEs typically strike-through usages of 
deprecated methods and I assume they will need to do something similar 
for methods associated with preview features.

-Alan