OSGi without the Eclipse
It's become common to equate OSGi with Eclipse or Equinox, but in fact other OSGi implementations exist. This post from JW blogger Oleg Mikheev fills a much needed gap - walking through the process of developing a Hello World bundle with Apache Felix and the IDE of your choice.

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com

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.

With JavaOne approaching in March and Sun dragging its feet to solve these issues, the Apache group decided to go public with its grievances. Just before JavaOne, it voted to give Sun 90 days to resolve the most important issues or it would follow the letter of the law and stop implementing Java standards. This would have essentially ended Apache's participation in the JCP. On March 22, Sun wrote a letter of intent promising to address Apache's major concerns. Hunter then posted a note, "The Day Java Opened Up?," to his Servlets.com Website.

Open source pipes

So has Java really opened up? Sun has agreed to make all future JSR licenses open source compatible. This, along with the increased availability of shared code and test kits to open source projects, could make the platform more open. Companies working on plumbing-level Java technology should be among the first to take advantage of the new changes, according to Apache cofounder Brian Behlendorf. "You want to release plumbing," he says. "Maybe companies will collaborate on these projects rather than compete." One such plumbing area, the JVM, could be the first to benefit, he says. "There has to be 100 JVMs out there," says Behlendorf. "Most of them are not the main product that any one company sells. I predict you're going to see a whole lot of open source JVMs out there."

But in all likelihood, it will be 2003 before these open source VMs begin to emerge. That's when Java 2 Platform, Standard Edition (J2SE) 1.5, a.k.a "Tiger," is expected; Sun has pledged it will release Tiger under open source-compatible terms. Though IBM and HP have no comment on whether or not they plan to implement open source JVMs, BeUnited, the open source BeOS standards group, has been following the Apache situation and has its eye on J2SE 1.5. BeUnited President Simon Gauvin says he has been in touch with the Sun engineer in charge of the upcoming Tiger release about the changes. He adds that if his group were to develop an open source JVM, then the changes made to J2SE "would matter a great deal to BeUnited."

Since Sun has yet to actually deliver on any of its promised changes, it is too early to see which, if any, open source projects outside of the Apache umbrella will benefit. One outstanding issue is that not all existing JSRs are covered in Sun's letter of intent. Sun has promised to change the license restrictions on all future JSRs, as well as 11 current JSRs that directly affect the Apache project, including JavaServer Faces, JavaServer Pages, and several JAX (Java XML) specifications. But that leaves the vast majority of Java open source projects incompatible for the time being.

Nowhere is this more strongly felt than in the J2EE space. Theoretically, future J2EE revisions will be open source compatible, and will even come with TCK access to some open source projects, but Sun is not saying when exactly this will happen. Because of the promised changes, HP, for example, says it expects companies to now collaborate much more freely on the "commodity implementations of standard APIs." But, when it comes to HP's J2EE software, the company is noncommittal on expressing whether or not Sun's changes will matter. For example, HP's free-of-charge J2EE application server, HP-AS, could theoretically be a candidate for an open source release, but according to HP's Competitive Strategies Manager Robert Gadsdon, Sun's changes, thus far, appear to be "very specific to the requirements of the Apache Web server" and "unlikely at this time to have a significant impact" on whether or not HP opens HP-AS.

Resources