Java Community Process To Change Charter To Encourage Public ParticipationJava Community Process To Change Charter To Encourage Public Participation

The Java Community Process (JCP) on Tuesday will ratify a new charter that should make the creation of Java standards more efficient and encourage more public participation in the process, according to a Sun Microsystems JCP manager.

The JCP has made key changes to JCP 2.6 that will make the process of finalizing Java Specification Requests (JSRs)--which ultimately can become Java standards--more transparent to the public, said Aaron Williams, executive relations manager for the JCP at Sun. The new JCP charter also should hasten the process of moving JSRs through the usual process of initial introduction, review and eventual finalization.

While the JCP has been responsible for creating Java standards for about five years, it has not done so without criticism from both the Java development community and vendors with a vested interest in the technology. The JCP, a group of vendors that create and finalize Java specifications into standards, has been criticized for taking too long to finalize Java standards, thus thwarting the evolution of the technology.

Some of the most recent fire about Java's standards and licensing model came last month when IBM, an active participant on the process, called publicly for Sun to allow for an open-source implementation of Java without requiring a Java license.

In an open letter written by Rod Smith, vice president of emerging technologies at IBM Software, the Armonk, N.Y.-based vendor encouraged Santa Clara, Calif.-based Sun to open-source Java, a move Smith said will promote Java as a platform even more than its current utilization.

Speaking to CRN last Friday, Bob Sutor, director of WebSphere infrastructure at IBM, said Sun and IBM will meet in the next week to discuss the letter and the possibility of making Java open source. "We think it's just so attractive--the notion of having a dependable, compliant Java implementation everyone can use, just like Linux," Sutor said.

However, the possibility of Java becoming an open-source platform in the near future seems slim. Early last week, Jonathan Schwartz, executive vice president of Sun's Software Group, repeated Sun's longtime contention that maintaining compatibility of basic Java implementations is key to the technology's survival. He said the current community model has proven successful at maintaining compatibility and promoting Java and that Sun sees no good reason to change the process at this time. However, Schwartz added that Sun executives are willing to discuss the matter with IBM.

Meanwhile, JCP 2.6 will introduce changes that should contribute to the group's efficiency in moving Java standards along, Williams said. One key amendment in the new charter moves an executive committee vote on whether a JSR should continue in the process to some time after the JSR's second review, rather than after its first review, Williams said.

Currently, it takes an average of nine months from the time a JSR is first submitted to the JCP to when it reaches its first review, which is when community members first get to see a draft of the spec. This is mainly because JSR specification leads are hesitant to go into first review with some of the spec work incomplete for fear the executive committee will vote down the JSR, Williams said.

There are two executive committees within the JCP, one to handle the J2SE and J2EE platforms and one to handle the J2ME mobile Java platform. About 30 companies and two individuals make up the executive committees altogether.

Moving the vote to after the JSR's second review should alleviate some of this fear and halve the time it takes for a spec to go into first review, Williams said. "We are expecting that average to come down closer to five months [because] spec leads will feel more comfortable going to review," he said.

JCP 2.6 also makes both draft reviews a JSR currently goes through available to the public, rather than just the second one, as the process is now, Williams said. This new way allows for "a great number of more developers to get involved early on in the process," he said.

The new setup also enables specification leads to hear feedback from anyone interested in that particular spec earlier in the process--regardless of whether the interested party is part of the JCP--about proposed changes or additions. This should hasten the process of finalizing a spec, Williams said.

"We found that spec leads appreciate more input early on because keeps them from having to solve a problem [that arises] later," he said. "Getting input from the first review is better than hearing it when the spec is fully baked."

Another change to JCP 2.6 requires specification leads to create a "transparency plan" when they submit a JSR for review before the JCP, Williams said. Such a plan could include required monthly updates on the proposed JSR to the community or a way for interested parties to sign up to an e-mail list so spec leaders can send out updates about the spec.

While JCP 2.6 does not require specific ways JSRs must be transparent to the general public, it does give the JCP executive committee power to reject a JSR if its transparency plan is not adequate for that particular technology. Prior to JCP 2.6, the "executive committee didn't have the opportunity to enforce transparency," Williams said.

The JCP has made some other minor tweaks to its charter. One gives JSRs more flexibility to be reviewed by both the executive committee overseeing the J2EE and J2SE platforms and the one handling J2ME. Since some specifications "span those platforms," spec leads now have an option to require that their JSRs be submitted to both executive committees so both "have responsibility for that JSR," Williams said.