Just a bunch of small improvements to the JCP

Simon Phipps talked about having a level playing field a while ago, and Sun's Rich Green indicated at Java One that the JCP would like to see more members. Ken Arnold talked about the reforms necessary in the JCP to make it happen. Let me throw a few softballs as well.

Compatibility is great. Everyone wants that. In practice compatibility is easy, too. It just takes a few things:

1. there is non-discriminatory licensed code to look at and/or reuse
2. there are non-discriminatory licensed specs, which are implementable, and are detailed enough to allow interoperability
3. there are non-discrimininatory licensed, extensive test suites to verify that the end result interoperates correctly with whatever else is out there

. With the Java 1.5 JSR, we've finally got one of the three, sorta, as that was the first Java specification release under a license that allows free software implementations. The official implementation and test suite have licences that fall short of the non-discriminatory goal.

The problem that Simon talks about, is real. A quasi-monopolist can ruin a platform for others. See the ongoing fight of the EU vs. Microsoft to ensure a level playing field in the Windows arena. Or see the fight Apache had with Sun to ensure that specifications coming out of the JCP can be implemented as free software, to allow a level playing field to exist between free and proprietary implementations of the 'industry standards'. As the times have changed, now it's Sun that's afraid of someone else putting the pressure on them by tilting the playing field to their favour, shifting the thinking from building a 'community' to creating good 'governance'.

For Java to be safe from someone tilting the playing field in their favour in the future, the JCP will need to open up radically, to embrace participation from new members on all levels. It needs to grow much further than the few hundred individuals and vendors that are in it today. It needs to put some power into the hands of the membership, so that anti-social behaviour by vendors can be dealt with effectively and publicly.

For that, it needs to come with full, mandated transparency on every JSR, no-strings-attached access to specifications and test suites, like W3C does. It needs to have a patent policy that requires disclosure of patents embedded in specified technology, and creates a patent covenant around each JSR.

It needs to make the life of Java developers and easier, not harder, as it does currently.

So, here is a small list of items to fix in an upcoming JCP 2.7:

1. The JSPA legalese required to participate is way too long, way too NDA-ish. I want to help improve specifications. Making all the individuals who'd be able to help spend their time dissecting 10 pages of dense legalese before they can help is not such a great idea.

   The JCP should either drop the JSPA for participating on the JSRs, or cut it down to one page with clearly spelled out rights and obligations of the membership.

2. The legal restrictions on participants in JSRs are unclear. When the call went around to join the Mustang JSR, I asked the spec lead what the legal implications would be on me as an independant implementor, but got no real reply. If Sun's spec lead on the Mustang JSR can't figure out what the legalese means, then there is someting seriously flawed with the system. It seems that those restrictions largely exist to resolve problems coming from the lack of a separate name space for draft specifications, and the resulting potential for confusion between partial and full implementations of the specs.

   Use the org.jcp.draft.* namespace for the draft specs, then.

3. Most core Java JSRs are not transparent, for members and non-members alike. If I want to know what's being cooked in JSR 277, to pick an example, I wouldn't be any wiser than I am now if I joined the JCP, as the spec lead is not encouraging public participation on that JSR, within or outside the JCP.

   JCP should mandate full transparency on JSRs by default, and have a jcp.java.net project associated with each JSR, with a public mailing list archive, RI source code archive and the TCK, as they are being developped, rather than leaving it up to spec leads to set their own rules on transparency.

4. JCP is currently focused on quantity, rather than quality of the specs. In particular in the area I am familiar with, Java 1.5, there are several APIs that are very poorly specified, and should have never become part of Java. Stuff like this is rather bad in an industry standard.

   There should be some effort to ensure quality: require two independant and interoperable implementations of a JSR for it to be allowed to move to the final vote, and require a certain amount of test and assertion coverage in the TCK.