News

JCP 2.6 opens Sun's Java process

• By John K. Waters
• March 16, 2004

A new version of the Java Community Process (JCP), designed to make developing Java standards more efficient and open to public input, was unveiled recently by the JCP Program Management Office and Executive Committees. JCP 2.6 is "more transparent, more participatory, and more efficient than the process has ever been," said JCP executive relations manager Aaron Williams.

The move comes amid criticism of JCP, centering mostly on the slow uptake of standards, from IBM and others.

Changes implemented in JCP 2.6 are intended to encourage greater public involvement in the formal procedure for creating and refining Java Specification Requests (JSRs), which are proposed new specifications or revisions to existing specs to the Java Platform. The JCP Web site lists more than 90 JSRs currently in development in the JCP program. The new version of the program includes a modified review structure, a shuffling of the JSR balloting periods and a new emphasis on "transparency."

That new emphasis can be seen in a significant change in the program's review structure. The life cycle of a JSR includes two review periods. In JCP 2.5, the second period was open to the public, but the first was open only to the Java community. Under JCP 2.6, both review periods will be open to the public.

"We are opening the JCP early to a broader set of participants," Williams told ADT, "which is something the spec leads have been asking us to do for some time now. They get a lot of good feedback during public reviews, and they want more of it. Also, by providing your spec to a broader audience earlier on, you can get a broader acceptance of it once it actually goes final."

"Spec leads" are the organizations in charge of the individual JSRs. They are responsible for delivering the three things required to complete a JSR: the specification, the reference implementation and the associated compatibility test suites.

JCP 2.6 has shifted the balloting timetable of the program to encourage spec leads to move their JSRs into the first review period with open issues. Under JCP 2.5, the executive committee votes on a JSR when it is first submitted, after the first review period and when all the deliverables are completed. Under JCP 2.6, that second vote comes after the second review period.

"We found that the spec leads were a little apprehensive about going into that first review period with any open issues," Williams explained. "They felt that the executive committee might conclude that they weren't doing their job. By moving that ballot back, we're trying to make the spec leads feel more comfortable about going into that first review period with more open issues, because that will provide an opportunity for the public to be more directly involved in answering those open questions. It's a way to get more comments and feedback from outside that expert group earlier in the process."

Changing the balloting should also make the JCP more efficient, Williams said. Under 2.5, it took an average of nine months for a JSR to get from submission to that first review period; Williams expects JCP 2.6 to cut that time to six months. "Making sure that JSRs and expert groups feel more comfortable about going to that first review period with open issues is going to cut that time," he said.

The new version of the JCP program will also include additional documentation and tools to make it easier for developers to participate as spec leads, which many perceive as a "black art," Williams said. And each JSR will now have its own community Web page designed to enable the spec leads to provide drafts of the specifications, as well as updates to the schedule and lists of open issues.

Work began on JCP 2.6 in April 2003 and was actually completed last November. The process of updating the Web site was finally completed last week. All JSRs that had been operating under JCP 2.5 will automatically migrate to 2.6, Williams said.

The Java Community Process has evolved considerably since it was first launched just over five years ago, observed Gartner analyst Mark Driver. He sees JCP 2.6 as an incremental step in that evolution, something of a refinement of the big changes that came with JCP 2.5. But JCP 2.6 does take a significant step by opening both review periods to public scrutiny, he noted.

"The process has been criticized for keeping the work a little too closed," Driver said. "It was very difficult to get a glimpse of the work in progress unless you were part of the working group. The rest of us couldn't log in and look at how some half-baked JSR was coming along. JCP 2.6 opens up the process and allows more community feedback. This is much more like the open-source process than the vendor consortium process we saw in the past."

Forrester Research analyst Mike Gilpin agrees that JCP 2.6 is an incremental refinement, but an important one. By opening the process to the scrutiny of developers who are outside the inner circle, JCP 2.6 brings what Gilpin calls the more desirable qualities of the open-source approach to the program.

"Open source tends to open up a project to scrutiny earlier in the process," he said. "JCP 2.6 is trying to balance the need to move the technology forward with the need to get broad participation by all of the stakeholders and making sure that all of their interests are protected."

Not addressed in JCP 2.6, Gilpin said, is the "unwieldiness" of the overall behavior of the Java community, especially where J2EE is concerned. "There are so many different JSRs that it's hard to know which basket of technology development initiatives is relevant to a particular future roadmap for application platform technology," he said. "There's no collective view."

Nevertheless, the JCP receives high marks from Forrester for its sheer effectiveness. "We see the JCP as one of the most effective standards bodies around," Gilpin said. "It doesn't have the same industry-independent status that an organization like the W3C has, but from a customer-centered perspective, it delivers the goods."