Over the weekend I happened across this post by Sun’s Dave Johnson, which in turn linked to this note from Apache’s Geir Magnusson (whose day job put him back in the news today). In short, the note proposes the creation of a new Apache incubator project, Harmony, that would have the following goals:
- Create a Compatible, independent implementation of J2SE 5 under the Apache License v2
- Create a community-developed modular runtime (VM and class library) architecture to allow independent implementations to share runtime components, and allow independent innovation in runtime components
The need for this is driven in part by the current inability to package Java easily. As Johnson put it,
Wouldn’t it be awesome if you could just apt-get, pkg-get or emerge JavaTM on your favorite open source *nix platform?
If it’s not clear to you, here’s what he means. Gentoo users such as myself use the command emerge to install new packages; typically, I simply type something like ’emerge mozilla-firefox’ and Gentoo goes out, downloads the necessary components, checks the dependencies, and installs the software. No fuss, no muss. Here’s what happens when I try to emerge the J2SE:
!!! dev-java/sun-jre-bin-1.4.2.08 has fetch restriction turned on.
!!! This probably means that this ebuild’s files must be downloaded
!!! manually. See the comments in the ebuild for more information.* Please download j2re-1_4_2_08-linux-i586.bin from:
* http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=j2re-1.4.2_08-oth-JPR&SiteId=JSC&TransactionId=noreg
* (select the “Linux self-extracting file” package format of the JRE
* and move it to /usr/portage/distfiles
Slightly less convenient, I think we can all agree. Why it has to be this way is part licensing and part ideology, but either way it’s not an ideal experience from either the developer or user perspectives. Harmony aims to address this and other concerns by creating a “Compatible, independent implementation of J2SE 5 under the Apache License v2.” An implementation that could be included in and made freely available to Linux distributions, for example.
In theory, it sounds like a good idea. Tim Bray thinks so, and he links to Java guru Graham Hamilton who also sounds relatively sanguine about the notion, if not exactly bursting with enthusiasm (Sun’s Simon Phipps is a bit less ambivalent here). There is, of course, no shortage of dissenting opinions, as evidenced by Miguel here. Miguel cites the inevitability of conflict with the current GNU Classpath, which is from where I sit a legitimate concern (see a refutation of Miguel’s take here).
The Classpath overlap, however, is not my principal concern with the Harmony project (here‘s a take from someone involved in both Classpath and Kaffe). Nor is it the lack of code [1] that some folks mention.
No, it’s the compatability issue that worries me. I know that the goal of Harmony is a 100% compatible implementation, but see the issues mentioned by Tim Bray here:
On the other hand, the Harmonians plan to achieve compatibility by passing the TCK test suite, which everyone says is tough and time-consuming; quite likely, more time-consuming than most individual pieces of bug-fixing. So that might get in the way of the kind of patching responsiveness weve gotten used to in OSS-land. [By the way, is it publicly known how long the J2SE TCK actually takes to run? Ive never seen that published.] I guess you could apply patches without doing a release and run an un-TCKed J2SE on an interim basis. That might make some people nervous; it would make me nervous. In fact I think the rules say you cant call it Java unless its TCKd, so I guess we need a new name; I propose JINJ.
In the end, as many have noted, producing a separate instantiation is likely going to be very difficult and timeconsuming, while introducing the possibility of fragmentation. Will interim releases wait or be released as forks? The prospect of JINJ is, to me, a real problem.
The Harmony folks do not, apparently, agree with me. See this bit from the FAQ:
Won’t this lead to fragmentation in the Java community?
———————————————————–We don’t think so. Our intent is to bring people together, let us share what we know, solve common problems, and collaborate on things where we can. A diverse Java community is a healthy Java community. Multiple implementations of the Java specifications show the value of Java – that we do have a specification, that anyone is free to make a compatible implementation, and that users of Java have the opportunity to run their Java code in more places, on more platforms. This is the central promise of Java, and we think that our efforts support his.
Why do I think it’s such a problem? Well, first because I don’t find that answer sufficient, and second because I’ve become convinced over the years that Java’s principle and primary virtue has been compatability. Yes, some will cite the *ilities (scalability, reliability, etc) or security as their motivation for selecting Java, but overall I think Java’s attracted the crowd it has largely because of the compatability it offers. I’m not naive on the topic; I’ve spent enough time in the field to know that cross-platform compatability is a relative term (trying moving a large application from WebLogic to WebSphere and you’ll see what I mean), but overall I think portability is far better in Java than in the alternatives.
This is why – and this may surprise some people (certainly it surprised IBM when we discussed it at the time of their open letter to Sun last year) – I’m actually not in favor of an open source Java. Or to put it more clearly, I’m not in favor of an open source Java that risks in any way the compatability of the platform. Not because I’m not a fan of open source – I am, and not because I think Sun’s been a perfect steward – they’ve been good, but not great. It’s because open source offers the opportunity for forking, and while that’s been a manageable risk for projects like Linux (depending on how you see the overall distro compability), Java’s a different animal. Java’s a platform whose credibility rests on its ability to run code platform to platform, but a platform whose advocates are not always a.) on the same page or b.) content to wait for consensus building.
If a governance model is devised by which the compability of Java can be guaranteed while opening the source, I’d be first in line to support it. But I haven’t seen such a model put forward yet; the threat of “not being able to call it Java” has never impressed me as being all that intimidating an obstacle for vendors over a certain size and with certain motivations. No, I tend to agree with my colleague who used Winston Churchill’s line last year when comparing the JCP to democracy during a JavaOne panel, calling it “the worst form of governance, except all other forms of governance.”
Ultimately I’d count myself undecided on the subject of Harmony’s merits, but I’m at least mildly concerned. That said, I think we’ve got a ways to go before we know what the impact of Harmony will be, and I’ll join Bray and the others in applauding the sentiment and goals of those involved with the project. I’d very much welcome a conversation with any of the Harmonians folks on these concerns, because I’m not the only one who has them. Meanwhile, best of luck to the folks involved, you’ve got your work cut out for you 😉
[1] An interesting (and potentially issue raising) tangent – see #11 from the FAQ here.
No Comments