JCP votes for Java EE 6: Apache says no in protest, SpringSource plays a deeper game

Oh, hey, look, Java EE 6 has been approved by the JCP [1]! Now it is all over but the shouting, and by "shouting" I mean "intensive work by IBM and Oracle and others to produce enormously complex and expensive implementations of the standard in their app servers." The approval of the standard did not really seem to be in doubt, but it's interesting to note (as you can on the above-linked page) who the naysayers were. The only no vote was from the Apache Foundation, which was not actually about Java EE 6 per se but rather about Apache's long-running dispute with Sun about the Java Compatibility Kit [2]. This dispute is in important one that makes my head hurt every time I try to wrap my little brain around it; basically, Sun only lets you use the JCK (which is the tool that determines whether your implementation of Java actually meets the Java standard) for free if you're intending to license your implementation under the GPL; Apache licenses things under its own open source Apache License, and says that this policy of Sun's is violating the Java Specification Participation Agreement, which states that specifications should be royalty free and ... yeah, I know, it's complicated. (UPDATE: And, yes, I've managed to botch this explanation. See the comment below from Stephen Coleborne [3] for a better version.) In this vote, the Apache Foundation specifically said that its "no" was "not a statement about the technical merit or quality of work done by the Expert Group to date, and if it were not for the unresolved non-compliance by Sun, Apache would most likely vote 'Yes'."

But SpringSource's reaction was more interesting -- they chose to actively abstain (as opposed to the Eclipse Foundation and Nortel, which simply didn't vote). The company offered its reasons -- no minimal Web profile, "as has become the choice of most enterprise Java users," JSR 299 is unproven, the end result doesn't match the original spec request. (Some of these complaints were also voiced by other committee members, like SAP, who nevertheless voted yes.) And yet this abstention -- not a yes, not a no -- intrigues me, and I'm trying to figure out what exactly it portends. Perhaps by not voting no, SpringSource's Rod Johnson, whose agreement to take a place on the committee was a turnaround on his part [4], is trying to show that he's not an obstructionist or an ideologue. And yet by not voting yes, he manages to keep SpringSource's distance from the latest Java EE standard. None of SpringSource's current products implement the Java EE standard; and now, with the absence of the lightweight Web profile SpringSource wanted, SpringSource senior vice president of engineering and product management Peter Cooper-Ellis says that the company will only implement the parts "that make sense [5]," which as I read it means that you won't see the any of the SpringSource servers bearing the Java EE 6 certification anytime soon.

I don't mean to imply the SpringSource was being disingenuous throughout this process -- certainly Rod Johnson's gushing blog post from a year and a half ago on Java EE 6 was genuine enough [6]. But I think that SpringSource believes that Java EE needs its ideas -- specifically, the concept that more lightweight app servers are the future [7] -- more than SpringSource needs the Java EE seal of approval. Maybe SpringSource thinks it will make progress on its own while IBM and Oracle are doing all that heavy lifting.