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.