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