Open, Independent JCP?
Independent Look At the Java Community ProcessSM Program in my href="http://weblogs.java.net/pub/wlg/20">first java.net blog
entry. The original title was "JCP Better than Open Source?" so you
might imagine my expectation for fireworks at the session.
Well, first off, the turnout was pathetic. Seems to me like the piss
poor voter turnout thing. Of course, those folks still like to bitch. Sigh.
Frank Sommers was allowed access to the JCP database to do a study on
the characteristics of the JCP so far in a piece called href="http://www.javaworld.com/javaworld/jw-11-2002/jw-1108-jcp.html?">Effort
on the Edge.
Is the java.net community going to kill the JCP?
Doug Lea pointed out that many things don't make sense as full blown
(de jure) standard. I think that, like any other premature
optimization, bringing things into a standardization process before they've
been fully baked in the heat of real-world abuse and competition is a
recipe for adding yet another backward compatiblity anchor around our
necks. Remember that in the JCP, backward compatibility is a huge
constraint. Given that constraint, the JCP should be much more conservative
in what they allow through since we're all going to have to live with it
for a long time.
Rob Gingell made some very nice statements that the JCP is really about
controlling the definitions of the java.* and javax.* namespaces.
Basically, things that don't belong in those namespaces have no particular reason to
go through the JCP. He was also very clear in saying that Sun is open to
many ways to improve the entire world of Java -- the core platform should only
represent a small part. That is, communities such as java.net are
resources which people can use to help others while helping themselves
without the constraints or goals of the JCP.
Is the JCP open or just a white glove around Sun's fist?
Jason Hunter ranted about the fact that Sun still has ultimate control
over Java since they have veto power and control most of the JSRs (and
certainly all of the core JSRs). The Spec. Leads in each JSR is basically
a dictator and pretty much do what they please (within the constraints of
the JCP). But, if people don't like that Spec. Lead, the JCP conventions
won't allow for a competing JSR to be approved. So, there's very little
incentive for the Spec. Lead to actually have to care about things like
Mark Hapner made a good point that one of the really great things about
the JCP is that it is also evolving. [In a lovely example of recursion,
the JCP is evolving through the JCP.]
Jason also noted that the Spec. Lead can foist onerous business terms in
addition to onerous technology.
Jason went on to rant about the fact that the JCP licensing terms often
force an all or nothing approach to approving/rejecting the JSRs. There's
no way to reject specific chunks and yet still remain in compliance. The
easy example here is the whole fiasco around the J2EE certification.
The Bottom Line
The simple fact is that Sun controls the definition of Java through both
its founder veto and through leading all of the core JSRs. Oh yeah, I
forgot to mention that the Spec. Lead organization cannot ever be forcibly
ousted. So, Sun has the power and has it forever (or until they give it up).