8008662: Add @jdk.Supported to JDK-specific/supported API

Martin Buchholz martinrb at google.com
Fri Feb 22 21:40:09 UTC 2013


Hi Joe,

On Fri, Feb 22, 2013 at 11:19 AM, Joe Darcy <joe.darcy at oracle.com> wrote:

>
>  Should third-party vendor extensions that are "supported" for public use
> by the third-party use jdk.Supported?
>
>
> No; as I envision it, the jdk.Supported annotation is only meant to convey
> supported-ness in the JDK of parts of the JDK.
>
>
Depends on what you mean by "JDK".  Suppose the icedtea project added a
public "supported" method usesSystemZlib().  It would be good to provide
guidance what package to put this in (org.classpath.* ?) and how to
indicate level of support (by the icedtea project).

Suppose the IcedTea project decided to officially support sun.misc.Unsafe.
 Would they do this by adding jdk.Supported annotation to their version of
Unsafe.java, even if their upstream chose not to?

  What about the X's in hotspot flags and the java tools command line
interfaces?

>
> The policy around command line interfaces is unchanged; the interfaces are
> mostly stable, but the more X's are in a flags name, the less stable it can
> be.
>

We all learned this by indoctrination from the local sensei greybeard, but
where is it documented for the wider world?

Perhaps Supported isn't a binary thing, but needs to capture different
levels of support?
Solaris has had such support levels.
A "beta" ("laba", "experimental") support level is very useful for
introducing new technology.

It's a very hard problem, especially in a 1000 flowers world.



More information about the core-libs-dev mailing list