The Java Community Process is evolving to accommodate the influence of open source.
SAN FRANCISCO-The Java Community Process is changing to adopt the influence of open-source software and open-source community practices.
Patrick Curran, chair of the JCP program at Sun, told eWEEK that the open-source wave that has changed the software industry is having no less of an effect on the JCP. Curran spoke with eWEEK at the JavaOne conference here.
"Open source and the effect it's having on the software industry is having a similar effect on the JCP, and we are likely to make changes in the process based on that," Curran said. "We like open source and the great benefits it has brought to the industry."
Yet with the changes in licensing and community development models afforded by open source, "we see increased pressure for openness and transparency to ensure that work is done in a publicly-viewable manner," he said.
The JCP is the governing body for Java and the Java platform and consists of expert groups that oversee the various JSRs (Java Specification Requests) that define the changes and additions being made to the language and platform. Although the work of the JSR working groups eventually winds up in public, it is not always done in a consistently transparent manner so that observers know what is going on at all points in the process.
In a recent speech, Rod Johnson, CEO of SpringSource, compared the JCP to the Russian commissar because of its perceived heavy-handed approach. However, Johnson joined a panel discussion on the JCP and said he now believes the organization is working to right itself and get in line with open-source practices.
"A lot of this is happening already," Curran said, noting that some JSRs are being handled in a completely open-source manner.
Of Johnson's commissar views, Curran said that "to some extent that is a view that reflects the way things were several yeas ago, and to some extent I understand and agree with much of what he was saying."
Part of Johnson's view was that the JCP should not standardize too early on various concepts. In particular, he said, the higher up a technology is in the software stack, the later it should be standardized so that the industry can get a chance to work out issues of adopting the technology.
"We're in the process now of discussing all of this within the various committees," Curran said. "We have a meeting in Paris in two weeks to discuss it, and within a year we'll be able to make some changes" to the JCP policies to accommodate the open-source tidal wave.
Meanwhile, in a different direction, the JCP also has approved the removal or pruning of some technology from the overall Java specification.
"We're defining profiles to enable you to slim down and get rid of some of the early specs that have been 'obsoleted,'" Curran said. "We're getting to the point where Java SE [Standard Edition] and EE [Enterprise Edition] are viewed as a little too big. But we have to be cautious because no matter how old something is, there is always somebody using it."