Summary
Sun's release under the GPL of the three Java editions means that open-source projects can make use of millions of lines of code that comprise Java SE, ME, and EE. Sun's implementations, however, are based on standards formed in the JCP process. JCP program manager Heather Vancura spoke to Artima about open-source Java's impact on the JCP.
Advertisement
With Sun open-sourcing Java, you may be wondering what role, if any, the JCP will play in Java's future.
According to Tim Bray, Sun's director of Web technologies, open-sourcing the implementation has nothing to do with the specifications upon which those implementations are built. And for any implementation to be able to use Java trademarks, including the Java name, or call itself compatible with a JSR, it has to pass the appropriate Technology Compatibility Kit test suite. Those TCKs, and their associated specifications, are developed through the Java Community Process, or JCP.
Artima spoke with JCP program manager Heather Vancura, asking her about the impact of open-source Java on the JCP:
The ... open-sourcing of Java technology is not likely to affect the JCP program. Open source is already a part of the JCP... Process changes that accommodated open source were introduced as early as 2002. The JCP Program adopted provisions in its governing rules that made open source licensing possible for those who work on Java specifications and create compatible independent implementations of the specifications. The changes were introduced ... with the help of a broad ... group of experts which included The Apache Software Foundation.
When the JCP started in 1998, open source, as a business model and as a methodology, was not accepted. By 2002 that had changed. The community had an expectation to utilize open source. The JCP program adapted to that change and made sure that open source was a way to implement the [JCP] standards. We anticipate that Sun's decision to open source their reference implementations of Java SE and Java ME will increase the expectations of the community for expert groups to behave transparently.
Today, Sun is the spec lead for the umbrella JSRs which define the components of Java SE, Java EE and Java ME. The [respective] expert groups work with the spec leads to determine which additional JSRs and other minor improvements will be included in each new release of the
specification. It also remains that final approval for all changes is made by a vote of the JCP Executive Committee... Sun's Reference Implementation of JSR 244, Java EE 5, was developed through the JCP program and has already been open sourced as Project GlassFish application server.
According to Vancura, if you care about the directions of Java standards, then voting in the ongoing EC elections is very important. Monday, November 13th, midnight Pacific Time is the deadline to vote. Voting takes place on a Web site operated by an independent third party at http://www.jcpelection2006.org. You have to be a member of the JCP in order to vote. Membership is free, although there is plenty of room to make online JCP membership signup easier.
Vancura explained that:
The Executive Committee [EC] ... guides the evolution of Java technology in the JCP. The EC represents both major stakeholders and a representative cross-section of the Java community. The EC is responsible for approving the passage of specifications—JSRs—through key points of the JCP program and for reconciling discrepancies between specifications and their associated test suites.
There are two ECs: the SE/EE EC oversees the Java
technologies for the desktop/server space, with responsibility for the Java Standard and Java Enterprise Edition specifications. The ME EC oversees the Java
technologies for the consumer and embedded space, with responsibility for the Java Micro Edition specification.
Each EC member impacts the future of Java by approving or disapproving draft specifications, giving or withholding final approval to completed Java specs and their associated RIs and TCKs, and reviewing maintenance revisions, according to Vancura. EC members also decide appeals of first-level TCK test challenges, when those arise.
Currently, there are seven candidates for the one open Enterprise/Standard edition EC seat, and three candidates for two open seats on the ME EC.
Do you agree with Vancura that open-source Java will only minimally impact the JCP?
My initial thoughts, after sleeping on it for a night, are that open source probably will not impact the JCP much, aside from the call for more transparency. I am not sure how the JCP could become more open without leading to conflicts in the standards around which Java is based. It's already a participatory community. Perhaps a seat (or seats) might be reserved explicitly for an "at large" representative of the open source community generally? Other than that, one of Java's strengths has been adherence to standards. As a Java developer and user of Java products, I want that standardization to continue, which will thankfully occur. Sun is basically acting here like the core team of Linux kernel developers - overseeing the entire process and ensuring that it stays "on track". I have no objection to that at all, at this point in time.
Every JSR delivers a Reference Implementation. Under which licence this RI will now be shipped? If this JSR is packaged as java.something or javax.something, what are the associated constraints? Should this RI be delivered as GPL also? Or it cannot be delivered as GPL because if it does so, it won't be possible to licence Java commercially. If RIs are open-source projects too, where these projects will be hosted? Apache? Going through the incubator?
I think if we consider the specification only, there is quite no impact on the JCP but because of the possible open-source nature of the RI development process, there is well an indirect impact on the JCP.
Previous Topic
