Newsletter sign-up

View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

The open road ahead

Is Java open enough for the rest of the open source world?

By Robert McMillan, JavaWorld.com, 04/12/02

It all began with a simple question. Jason Hunter, Apache developer and Java guru, wanted to create an open source reference implementation and Technology Compatibility Kit (TCK) for his Java standard, currently under parlance with the Java Community Process (JCP). The standard -- Java Specification Request (JSR) 102: JDOM 1.0 -- is based on his Java-based document object libraries. Though Apache had been an active JCP participant and a member of the Executive Committee since 2000, Hunter knew some incompatibilities existed between Apache's open source license and JSR 99: Java Specification Participation Agreement (JSPA) -- Sun Microsystems' legal agreement that defines how Java standards are developed. But nobody at Apache was fully aware of the underlying issues.

So, in an effort to see what would happen if an open source project tried to participate in JSR creation, Hunter asked the JCP group at Sun Microsystems if he could release an open source reference implementation as well as an open source TCK for JSR 102. As the JSR's spec lead, Hunter felt it only right that he be able to create an open source reference implementation and TCK.

Sun's response: "No." The JSPA dictated that JSRs use a copyright license that enforces compatibility. Unfortunately, enforcing compatibility is not permitted under an open source license, so the two licenses could not co-exist.

That was just the beginning. The further Hunter looked into the JCP, the more problems and incompatibilities he found. Though the Sun-led Tomcat JSP (JavaServer Pages) server was widely viewed as a successful example of an open source reference implementation of JSP, the JCP requirements had changed since Tomcat was first released. As the JCP had become more formalized, the JSPA rules had changed, making it now technically illegal to create another Tomcat.

"[The JCP] had become more confidential, more restricted," says Hunter, "We were better off four years ago." And worse, because the servlet standard implemented in Tomcat had been absorbed into the umbrella J2EE (Java 2 Platform, Enterprise Edition) standard, it now technically violated the J2EE JSR 151 to implement a standalone servlet engine -- something that dozens of commercial companies were already doing.

There were more problems: Any project that wanted to test JSR compatibility needed to run a complicated TCK, supplied by the spec lead on the related JSR. Because of the complexity of these TCKs, most required tens of thousands of dollars in engineering support before you could properly interpret their results. Not a problem for the Hewlett-Packards (HP) and BEAs of the world, but a definite barrier for noncommercial open source projects like Apache. Further, these TCKs could not be released under an open source license. Finally, some parts of Java are so difficult to test -- Swing and Java's bytecode verifier, for example -- that the JSPA dictates that implementers must simply use the code defined in the particular JSR. Hunter found that this shared code's license was incompatible with an open source license.

 

XpoLog Center Correlate application logs with server metrics - XpoLog

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.