Will You See Open Source J2EE Implementations? Not Likely.

Editor's Note: O'Reilly & Associates' senior Java editor Mike Loukides revisits Sun's positioning on an open source J2EE and its effects on JBoss and other open source J2EE projects.

I wrote "Will You See Open Source J2EE Implementations?", about four months ago, at the end of September. Not much has changed since then. Sun still hasn't certified JBoss, and persists in saber-rattling to scare off others who might want to do open source implementations of J2EE technologies. At the same time, Sun loves to have Kodak moments with some parts of the open source community -- most notably, Apache -- who increasingly feel used and abused.

The Apache group has made a number of suggestions for changes to the terms on which members participate in the Java community process. I won't go into detail on these suggestions, but two are extremely important to the continued success of Java. First, Sun cannot continue to have licenses that prohibit compatible open source implementations. That sort of control is probably indefensible legally, and it's certainly offensive to anyone who is interested in developing open software. Second, Sun needs to make it easy for nonprofit groups (including open source and academic groups) to perform compatibility testing. The current situation, in which compatibility testing is prohibitively expensive, is not fair, not in the interest of the Java community, and not even in Sun's interest.

One thing Sun could do to push Java's acceptance forward would be to release the compatibility kits to the open source process. That would reshape the Java market in interesting ways. It would require Sun to give up some control -- but practically speaking, this loss of control would be minimal, since the JSR specification lead is responsible for the official compatibility test kit. I'm sure that Sun worries that an open source compatibility test would risk splintering Java into different camps surrounding different compatibility definitions. But with the JSR spec lead in control, that's unlikely to happen. The open source communities have been extremely good at preventing their standards from diverging -- there are no incompatible implementations of Perl, of Ruby, of Python, or of any significant tool that I'm aware of.

Furthermore, open source compatibility kits would make compatibility testing even more rigorous: you'd have BEA developers testing IBM's products, finding the incompatibilities, and submitting tests for inclusion. You'd have IBM developers testing iPlanet. And so on. All of these tests that break competitor's implementations wouldn't necessarily be included in the official compatibility test, but the open source process would get these incompatibilities on the table, making it possible to discuss intelligently what compatibility should really mean.

I don't think Sun will take a step this bold, though it would be in everybody's interest. But we can call on Sun to establish a level playing field in which all Java developers, regardless of their funding or licensing requirements, can participate. Simply put: JBoss is an excellent piece of software; it's one of the best J2EE servers around, at any price. If JBoss is not compatible for legitimate technical reasons, fine. But if JBoss can't be certified because Sun won't test it, then certification is meaningless.

Mike Loukides is a senior editor for O'Reilly Media, Inc., with a focus on developing titles on Java, UNIX utilities and system administration.

Return to ONJava.com.