Preview APIs for preview features -- JDK 14+

Alex Buckley alex.buckley at oracle.com
Wed Aug 7 15:03:34 UTC 2019


On 8/7/2019 4:00 AM, Gunnar Morling wrote:
>> Joe Darcy has proposed that associated APIs are annotated explicitly
>> (e.g. @java.lang.annotation.PreviewFeature) so that their use can be
>> detected at compile time.
> 
> I think that's a very useful addition.
> 
> IIUC, this is only geared towards usage within the JDK APIs themselves;
> maybe it could be considered to widen the scope of the proposal and enable
> usage of this functionality by 3rd party APIs? Specifically, I'm thinking
> of supporting similar, already existing annotations, e.g. @Beta in Guava or
> or @Incubating in Hibernate. 

There's a misconception in your model of "preview APIs", regrettably 
caused my use of the term as shorthand in the subject line. Let's be 
clear what we're discussing: an API defined by the Java SE Platform that 
is intimately connected with a preview language/VM feature. (JEP 12 
refers to this as an "essential" API because the JLS cannot avoid 
referring to it in normative text; see the JEP for examples.) If the 
preview language/VM feature changes or disappears, then the API will 
most likely change or disappear too. We are NOT looking to have APIs in 
the Java SE Platform that are "standalone" (independent of preview 
features) yet impermanent and in search of developer feedback. We have 
already settled on incubating APIs (JEP 11) as the mechanism for 
"standalone" impermanent APIs. Incubating APIs are deliberately kept out 
of the Java SE Platform (recall their `jdk.incubator` module and package 
prefix) to ensure developers realize that their use is risky.

Alex


More information about the jdk-dev mailing list