<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Martin,<br>
<br>
<div class="moz-cite-prefix">On 2/22/2013 1:40 PM, Martin Buchholz
wrote:<br>
</div>
<blockquote
cite="mid:CA+kOe0_6z6qXm7+EbZvjuUw+H8KoHr2xnC3pXqL45v10miY5YQ@mail.gmail.com"
type="cite">Hi Joe,<br>
<br>
<div class="gmail_quote">On Fri, Feb 22, 2013 at 11:19 AM, Joe
Darcy <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:joe.darcy@oracle.com" target="_blank">joe.darcy@oracle.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div class="im"><br>
<blockquote type="cite">
<div class="gmail_quote">
<div>Should third-party vendor extensions that are
"supported" for public use by the third-party use
jdk.Supported? </div>
</div>
</blockquote>
<br>
</div>
No; as I envision it, the jdk.Supported annotation is only
meant to convey supported-ness in the JDK of parts of the
JDK.
<div class="im"><br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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?</div>
</div>
</blockquote>
<br>
For some definition of "JDK", IcedTea is "JDK" too since they
provide a JDK distribution, one at least a little distinct from
plain OpenJDK and also distinct from OracleJDK.<br>
<br>
The long-standing problem I wanted to address was clearly indicating
whether or not the upstream code in shared JDK 8 sources was
regarded as a public API or not. So I don't think it would
necessarily be inappropriate for a hypothetical org.classpath type
to use jdk.Supported, but I wasn't really thinking about that use
case.<br>
<br>
<br>
<blockquote
cite="mid:CA+kOe0_6z6qXm7+EbZvjuUw+H8KoHr2xnC3pXqL45v10miY5YQ@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
</div>
<div> What about the X's in hotspot flags and the java tools
command line interfaces?</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div class="im"> <br>
</div>
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.</div>
</blockquote>
<div><br>
</div>
<div>We all learned this by indoctrination from the local sensei
greybeard, but where is it documented for the wider world?</div>
</div>
</blockquote>
<br>
There is some approximation to that guidance in the java man page;
options without a "X" prefix are described as "standard" and ones
with at least one "X" are described as "non-standard." Not all XX
options are included in the man page.<br>
<br>
<blockquote
cite="mid:CA+kOe0_6z6qXm7+EbZvjuUw+H8KoHr2xnC3pXqL45v10miY5YQ@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
</div>
<div>Perhaps Supported isn't a binary thing, but needs to
capture different levels of support?</div>
<div>Solaris has had such support levels.</div>
<div>A "beta" ("laba", "experimental") support level is very
useful for introducing new technology.</div>
<div><br>
</div>
<div>It's a very hard problem, especially in a 1000 flowers
world.<br>
</div>
</div>
</blockquote>
<br>
Yes, I'm vaguely aware that Solaris has had a rich taxonomy in this
space and there are, IIRC, dtrace tools to audit if you are calling
any sufficient unapproved APIs. However, at least as a first cut, I
think a binary supported / not-supported distinction captures at
least 80% of the distinction that needs to be made for the purposes
of the JDK. Anything more involves much less favorable complexity vs
benefit trade-offs.<br>
<br>
-Joe<br>
</body>
</html>