Have you ever pulled at a small thread, hoping to stop it before it eats into the very heart of the fabric and dismantles the whole garment? What started out as small, insignificant issue has suddenly turned into a major showstopper! I think this may be happening in the J2EE space and if we aren't too careful, we'll be left with nothing of any significant use.
I am, of course, referring to the current and very public debacle with JBoss and their push to become J2EE compliant. This is not a tussle between good and evil, nor is it a tussle of David-and-Goliath proportions (as Sun has been known to refer to it on occasion). To say so would merely dramatize it more than necessary. The media is being played and, all credit to Marc Fleury, he is playing them like a fiddle. Just look at all the free publicity he has managed to stir up for JBoss through all the major news outlets. Bottom line, you don't have to look far to find a JBoss story.
What is the real story? I have talked to both sides over the last few months, trying to get at the fundamental problem. I have talked to JBoss developers and other J2EE licensees to get their views. I have even listened extensively to various users in a variety of mailing lists and Web forums.
There's a lot of noise being made about JBoss becoming certified. Sun's Rick Saletta, group marketing manager responsible for J2EE licensing, claims JBoss needs to license the J2EE compatibility test suite. There are suspicions that JBoss won't pass the Test Compatibility Kit (TCK), but JBoss claims it will. While neither side is legally allowed to use the TCK until JBoss licenses it, I would wager that the tests have probably already been run by both sides. Fleury tells me that issues previously pointed out by Sun that would make them fail the test have been addressed (
So, with that, let's assume for a moment that the issue isn't technical. What else could be stopping the official J2EE logo from being applied to JBoss?
This is the question I asked Fleury.
"The J2EE brand is not a seal of quality; it is just a brand. The Sun reference implementation is certified, yet not fit for development or production." While, technically, I can't argue with him there, the certification is surely a contract of trust. When a developer calls a particular API or utilizes a library, it has to behave as the specification spells out. It is the J2EE logo that tells the developer that the application server has passed all the tests.
Fleury responded by saying that the J2EE specification "is vague, with many issues left to the vendor," and was quick to point out that any failing of expectation from any JBoss API call was quickly reported and fixed by their large community of developers. I imagine this is one of the strengths of the open source model.
JBoss say that the J2EE stack only makes up around 20% of their code base with their AOP framework contributing to the larger part. Fleury has said he and JBoss are still committed to supporting the J2EE standard and will, if asked, even contribute the AOP framework into the JCP process.
Fleury feels he doesn't want to pay for the J2EE brand just yet; the JBoss community at this moment doesn't need it. This stance will surely upset a number of other J2EE licensees who have had to toe the line and pay for the privilege of being J2EE certified. I asked a number of them about this, and while they didn't want to be named, it's fair to say they weren't too impressed with JBoss, and many of them were asking for JBoss to simply remove all mention of "J2EE" from their documentation and Web site until they are certified.
The question remains: Where will it all lead? Is JBoss pulling at the thread of the J2EE T-shirt? Is the J2EE "brand" at risk? Or is the API still safe?
When not answering your e-mails and working on the next issue of JDJ, Alan heads up a small team dubbed the "Thunderbirds of the Java industry," providing on- and offsite rescue for Java projects in trouble. For more information visit www.javaSOS.com.
You can also read his blog: http://alan.blog-city.com.