Sun's Java body to open smoke-filled rooms

More than a year after coming under pressure to break its corporate bias and to woo individuals, the Java Community Process has responded.

The body's announced proposed changes to the way it discusses, manages and votes on the Java language and platform. If accepted, the changes will be adopted by the JCP next month.

However, the group's sidestepped at least one crucial issue that could weaken its proposals and undermine its efforts to modernize and reach out to individuals. The current round of changes won't include modifications to a densely worded and complicated legal document that governs internal discussions and gags the very individual members it wants - and needs - from speaking to the wider world.

Also, there's a huge void over the future of Test Compatibility Kits (TCKs), essential to certifying that your Java implementation does not fragment the official spec. TCKs typically contain vendors' intellectual property (IP) under licenses that open-source projects and vendors cannot swallow, so they cannot be "officially" certified as compatible - hurting their adoption.

The JCP has said its Java Specification Request (JSR) 2.15 maintenance release for JCP 2.7 will not consider issues that are "difficult to implement or that require changes to the JSPA."

The JSPA is an onerous and confusingly worded 20-page legal contract with Sun Microsystems, which created the JCP more than 10 years ago, that says what you can - and can't - talk about outside the JCP. Participants writing, blogging or discussing about JCP meetings do so in contravention of the JSPA and at their own legal risk.

The JSPA was created to make a safe environment for technology companies talking about their intellectual property without exposing it to outside scrutiny.

The agreement, though, dates from a time when Java was an application server and middleware play where ideas came from big vendors in tight competition with each other, and is thoroughly at odds with today's culture of innovation from the community, where ideas are blogged and openly discussed.

Previously, current JCP chairman Patrick Curran has expressed a belief that the JSPA could be re-worded for simplicity and brevity - taking it down to one or a few pages.

On TCKs, JSR 215 is ambiguous. It will consider setting "minimum requirements" for TCKs and move the disclosure of TCK and other business terms to a point earlier in the process. This suggests you'll simply have a better idea of what vendors' IP a given TCK contains, but you still won't be able to use it if you're an open-source project or company.

Last year Curran expressed a belief in the need to make the JCP seem less like a closed shop by opening up meetings to outsiders and individuals, and by opening up the voting process.

JSR 215 suggests Curran got the big vendors that still dominate the JCP to come around to some of his thinking on this. His work may have become easier thanks to the fact Sun - which leads 30 per cent of all the Java specs - could get bought by Oracle and has become less obstructive.

In the interests of greater transparency, JSR 215 has suggested that observers be allowed on to expert groups, in addition to active members, while spec leads like Sun may be asked to provide regular updates to changes on Java that - in-turn - may get posted to a public web site.

To garner greater feedback on proposed changes JSR 215 will consider changing the Community Review to Early Draft Review and making it open to the public participation. Voting may also change: super majority ballots will be needed for all proposed changes, not just changes to Java Standard or Mobile editions.

You can read the full JSR here. ®