jar file man pages - was Re: trove-2.0.4 [LSARC/2009/262 FastTrack timeout 05/05/2009]

[James Carlson]

Garrett D'Amore writes:
> Mark A. Carlson wrote:
> > Let's keep in mind that we are trying to document (in an easily 
> > accessible place) the
> > interface classification of the OpenSolaris instance (not the Java 
> > interface across platforms).
> > Given that we need to do this without massive patches to the upstream 
> > code, and that
> > Java projects should use whatever native mechanism exists to document 
> > the classification
> > across platforms, the OpenSolaris man page seems to be the best place.
> 
> I remain unconvinced that we (OpenSolaris) should even be concerned 
> about stability of Java APIs upon OpenSolaris.  (With the possible 
> exception of APIs that are designed specifically to *support* 
> OpenSolaris itself.)
> 
> Do other members see value in having another layer of commitment and 
> review beyond whatever is already done as part of the Java community?

It's not "another layer of review."

It's architectural review as required by the process.  No matter how
important a project team may be, we simply do not defer to project
teams to do all architectural review on our behalf.  There's only one
ARC, and the system is designed that way on purpose.

So, JCP may do whatever reviews it desires in its own way (as may
other quasi-ARC-like bodies, such as CLARC and Sun Ray ARC), but to be
shipped as a Sun product -- including but not limited to being part of
the OpenSolaris distribution -- it's necessary that the engineering
work goes through architectural review.

In this case, I think we *are* concerned about advertising the right
stability level for these interfaces, because that's an inherent part
of software design, and not just some artifice that comes out of the
ARC.

If there's some local definition of stability levels and reference
documentation, and these are well understood by users, then that's
great.  It doesn't matter to me much that it's not identical to our
taxonomy or to man pages.  We may as well use what's natural (and in
fact require its use in all reviewed projects) so that users will
understand it better.

However, I do not agree that this means that we take a pass on it.  If
that's what we're planning to do (or if it's what you're suggesting
here), then either (a) Java needs to create a SAC-sponsored process to
play nice with the rest of us or (b) we need a much bigger rule (from
the CTO's office) giving Java a get-out-of-ARC-free card.  I don't
think we can or should do that on our own.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677