Java Community Process: Still Making Progress on Reform

When the Java Community Process (JCP) set out four years ago to take advantage of the Oracle acquisition to implement some much needed reforms, the Java standards organization started with what JCP Chair Patrick Curran referred to as the "low-hanging fruit."

That first Java Specification Request, JSR 348, was all about transparency, participation, agility and governance. It was approved without much fuss. A year later, the JCP sought to merge the two JCP Executive Committees (ECs) -- the SE/EE EC and the ME EC -- under JSR 355. That plan was also approved.

By 2012 the JCP was ready to reach a bit higher in this metaphorical fruit tree, into a tricky tangle known as the Java Specification Participation Agreement (JSPA). Issuing JSR 358 ("A major revision of the Java Community Process") around last year's JavaOne, the JCP started the process.

Reworking the JSPA is a much bigger challenge than anything the JCP has done so far in this multi-year makeover, so no one expected the organization to be finished by this year's JavaOne. JCP Chair Patrick Curran was on hand again at this year's event, and he reported that there has been progress, but offered no specifics.

"The JSPA is big, and it's scary," Curran said. "And you have to be careful what you touch. It's just like modifying legacy code. Sometimes you don't know why some language is in there, so you've got to be careful."

The JSPA sets forth the basic legal structure that allows companies and individuals to participate in the development and distribution of specifications, reference implementations, and technology compatibility kits (TCKs) within the JCP. The current version was created in 2002 through JSR 99. A lot changed in the decade that followed, and sponsors of JSR 358 argue that it's high time for the JCP "to revise this document to ensure that it meets our current needs."

Part of the reason the JCP is working to reform its sign-up contract is that the organization wants to make it easier for individuals to participate in the community, Curran said.

"They're the ones who are actually doing the work," he said. The JCP wants to attract more individual members, he said, because they produce JSRs that are more likely to fit the real needs of Java developers, and decrease the number of "ivory tower" JSRs.

Toward that end, the JCP launched the "Adopt a JSR" program, which encourages individual members of the community to "adopt" a spec request by following its progress, supporting its expert group, and/or reporting back to the wider community on its progress and evangelizing its benefits.

The primary vehicle for the Adopt-a-JSR program is the Java User Groups (JUGs), which can reach out to their memberships and promote participation. In fact, the program is considered "JUG-lead," and was the brainchild of two user groups: the London Java Community in the UK and SouJava in Brazil, who approached the JCP with the idea. Both are voting members of the organization. The list of participating JUGs also includes GoJava (Brazil), Houston JUG (US), and Chennai JUG (China).

The program has been very successful, Curran said: 11 JSRs have been adopted so far, and 18 JUGs are contributing to the Java EE spec.

"This is one of the best things to happen to the organization," Curran said. "It has added some great energy and real enthusiasm."

Posted by John K. Waters on October 9, 2013