What Sun open sourced, exactly

It's easy to get confused by all the knobs and levers that add up to Java and even more confusing when Sun announces that it's open sourcing something that's Java-related.  For years now, IBM and others have been pressuring Sun to open source Java and the idea of doing so has been the subject of significant controversy in the industry.  So, when at JavaOne this year, Sun announced that it would be open sourcing a reference implementation of the enterprise version of Java, you can imagine how this could easily be viewed as Sun finally granting those who've been pressuring the company their long term wish.  As can be implied by a blog entry by IBM's Vice President of Standards and Open Source Bob Sutor, this isn't exactly what IBM has been hoping for.  Said Sutor, referring to what he had written, "I want to make it clear that even with the above comment, I think Sun's move to continue to open source these sorts of things is very welcome."

So, what exactly did Sun open source?  Before I answer, let's first get some branding issues out of the way.  For those of you not totally up to speed on how Java is divvied up, you should know that there are several major classifications of Java, and three you hear about most often.  Of the three, the baby of the bunch, aka Baby Java, is called J2ME or Java 2 Micro Edition.   This is the version of Java that runs on mobile devices like BlackBerries and cell phones.   Then, there's the middle child, aka Little Java, that's officially called J2SE or Java 2 Standard Edition.  This is the version of Java that you'll most often find on notebooks and desktops.   And finally, there's Big Java, aka J2EE or Java 2 Enterprise Edition.  This is the version that usually runs on servers and that's synonymous with the term "Java application server."

A fourth version that doesn't get discussed as much, but that's just as important as the others, is JavaCard, the version of Java that is on many smartcards.  Not surprisingly, as implied by "baby, little, and big," these different versions of Java are capable of different things and the bigger you get, the more things they're capable of.  J2EE can do many more things than J2SE can, and so on down the line.  The capabilities are largely defined by their footprints--the amount of resources they take up.   A smartcard doesn't have nearly the resources that a server does.   Therefore, JavaCard isn't nearly as capable as J2EE.   Microsoft's .NET is organized in a similar fashion (for example, for PDAs, there's .NET Compact, sort of the .NET equivalent of J2ME).   For each of the Java "platforms,"  there is an official specification known as a Java Service Request (JSR) that describes in painstaking detail what any vendor's implementation of any of the platforms must do in order to claim they are certifiably J2ME-, J2SE-, or J2EE-compatible.  The organization that oversees these specifications is the Java Community Process (the JCP),  and both IBM's WebSphere and BEA's WebLogic are examples of Big Java implementations that are certifiably compliant with the JCP's J2EE JSR #151.

Deep inside these platforms is the Java Virtual Machine (the JVM) and a core set of accoutrements or "classes" that go with the JVM.  This bundle of core functionality is called the Java Runtime Environment or JRE.  When I said that J2EE is more capable than its siblings, the truth is that the JRE inside of J2EE and J2SE are the same thing.  What defines the difference in the capabilities of the two is their programmability, which itself is manifested in the programmable classes that accompany each.  J2EE has a JRE that's surrounded by a different set of programmable classes -- ones that are applicable to application serving -- than what you'd find with J2SE.  Why go to all the trouble of explaining this?  Well, it's very relevant to what Sun open sourced this week at JavaOne.

First, going back to the certifiably compatible implementations of the various Java platforms, if you're a Big Java maker like IBM or BEA, then the version of J2EE that you must be compatible with in order for your product to be viable in the market today is version 1.4.  When the version number changes, so does the JSR.  Before there was JSR 151 (J2EE 1.4), there was JSR 58 (J2EE 1.3).  So, for starters, as I understand it, J2EE 1.4 is the last version of J2EE that will use the J2EE acronym.   Going forward, Sun is ditching the acronym J2EE and replacing it with "Java Enterprise Edition."   No "2" anymore.   Instead, as demonstrated by what was formerly known as J2EE 1.5,  the follow-on to J2EE 1.4 is now just Java EE 5 (aka JSR 244).  As can be deduced from the fact that the Big Java vendors are currently focused on J2EE 1.4 (JSR 151) certification, the Java EE 5 specification has not yet been finalized.  If it had been, then all of the various Big Java vendors would be racing to get their implementations of the specification certified.  According to JSR 244 central, Java EE 5 is "targeted to ship in the second half of 2005."  So who cares about all this nuanced stuff?

Well, now we get to what Sun announced at JavaOne.  It did not open source Java. Sun open sourced its implementation of the as-of-yet unfinished Java EE 5 specification.  Not the currently-in-circulation implementation of J2EE 1.4.  And certainly not the JRE that lives or will live at the heart of any J2EE or Java EE implementation, which IBM no doubt would love to see get open sourced. 

So, now come the implications.   Things are going to get interesting as a result of this.  For example, in the same way that the open sourcing of previous bodies of source code have resulted in establishing certain de facto standards, Sun's open sourcing of its Java EE 5 "Reference Implementation" could turn that reference implementation into Java EE 5's center of gravity.   If you're JBOSS, for example, (and I haven't asked JBOSS CEO Marc Fleury about this), does it really make sense to pour significant resources into developing your own implementation of Java EE 5?  Or, should you just take the one that Sun open sourced, add your own mojo to it, offer some fee-based support, and continue on your merry way?  Or, what if you're a small software company that would love to be redistributing an implementation of Java EE 5 as a part of your solution?  Do you go with one of the other three open source implementations (JBOSS, JOnAS, and Apache's Geronimo) or do you go with what will surely be perceived (whether true or not) as the gold standard (Sun's reference implementation)?  After all, it comes from the inventors of Java and Sun's engineers are some of the best in the world.   I don't mean that Sun's engineers are better than IBM's or the ones working on JOnAS or JBOSS.  But could there really be that much of an appreciable difference in the final product? (Answer: perhaps only in specialized instances where a Java EE vendor does something like Big Java clusters or grids.)

Lest you feel as though I'm leaving out certain pertinent details, here's more.   Just because Sun open sources its reference implementation doesn't mean that, suddenly, there will be thousands of software vendors distributing Java EE solutions.   Here again, things are complicated.  If, for example, I start a company called David's Software and I start to distribute Sun's open sourced implementation of Java EE 5 without changing one line of code (even though it's open sourced), Sun might cut me a break on what is otherwise a fairly significant cost: compliance certification. Chances are, I won't have to get it certified because it already will be (just as long as I don't mess with the code).  If Sun does force re-certification, it will be an error in their judgement.

Beyond certification, we're still not in the clear yet.  For example, not only is there normally a cost associated with certification testing, but there's also a cost associated with putting the Java trademark on my software (something that buyers actually look for).   One of the little known facts (some might say dirty little secrets) of Java is that to use any of the Java trademarks (Java, J2EE, Java EE, etc.) in your sales literature, Web sites, or on your software, you must license the trademark from Sun.   Not only that, it doesn't matter if you're using someone else's code that's already been certified.  For example, the ObjectWeb Consortium recently achieved J2EE 1.4 certification for its Big Java implementation called JOnAS.   The consortium has also licensed the Java trademark.  But Red Hat, which makes the JOnAS implementation available to its Linux customers, cannot say it has a J2EE or Java server.  Check Red Hat's literature.  Everything is perfectly worded so as to avoid any chance of trademark infringement.   Red Hat is allowed to say it has "an application server for running Java applications" but it cannot say "we have a J2EE 1.4-compliant application server."  If it did, rest assured that Sun's legal eagles would move in for the kill.

To give its reference implementation a better shot at becoming the gold standard, Sun could relax the trademark licensing terms, but now we're getting much much closer to what IBM is after.  Of the many things that IBM wants, elimination of the testing and trademark fees has long been on the list.  So, if I had to guess, Sun won't be relaxing the trademark licensing terms anytime soon.   But for IBM to re-up its Java contract for 10 years the way it did  while backing Solaris (and for Sun and IBM officials to be so chummy with each other at JavaOne), Sun had to have made some compromises. (OK newshounds, git your noses out.)  

Another issue that will affect adoption of Sun's reference implementation is the open source license that Sun has applied to it: the CDDL.   Although the CDDL is regarded as a good open source license that drew from the widely respected Mozilla Public License, it isn't the GPL and not everyone is feeling the CDDL-love quite yet.  So, for example, if you're IBM and you just acquired the GlueCode team whose work is based on the Apache Project's Big Java (Geronimo), chances are you're not about to jump ship to an entirely different code base and license anytime soon. Nor might IBM want to so readily anoint Sun's Reference Implementation of Java EE 5 as the gold standard just after acquiring GlueCode.  Maybe now you can also see the other between the lines shot this was at IBM.  Whether or not open sourcing the Java EE 5 Reference Implementation will render the GlueCode acquisition less significant remains to be seen.  But you know it was on the minds of Sun executives.