sab39 ... The reinvigoration of Classpath?

9/21/2007

(Disclaimer: I'm just observing all this from the sidelines; my opinion is almost entirely derived from Planet Classpath and the Classpath mailing lists. If I'm wrong on some salient point, please comment and let me know!)

I'm very pleased to see that the Classpath project seems to be picking up some of the steam it lost on the announcement of OpenJDK. I have mixed feelings about OpenJDK itself: on the one hand, Sun did exactly the right thing by releasing the JDK under the best possible choice of license as we'd all wanted for years; on the other hand, I've seen at least two blog entries on Planet Classpath in the past week that were variations on "hooray, the trivial patch I submitted to OpenJDK the week it was released has been accepted a mere three months later!"

IcedTea appears to have picked up some of this slack and last I heard had built a mostly-working Java implementation by plugging in Classpath code to fill the holes in OpenJDK. Haven't heard much about it lately though - has development stalled or are people just not blogging about it?

However, part of me feels that IcedTea is approaching the problem from the wrong end. The code that the Classpath developers have labored over for ten years deserves a higher place than being used as filler to patch the holes in an inferior, ex-proprietary codebase. I'm not trying to argue that Sun's code is "bad" or that Classpath's code is perfect, but I do know that code developed in the bright light of public view, with no schedule pressures other than "when it's right", is invariably [UPDATED: Jeroen points out in the comments that this isn't so invariable after all] higher quality than code developed inside a large, bureaucratic organization with constant pressure to ship to a deadline. The fact that these things have historically affected Java's development is apparent in the public API: public members whose types are nonpublic, public RCSID fields, serialVersionUID fields defined on interfaces.

The difference is apparent in the sheer size of the codebases - the JDK is several times the size of Classpath, despite Classpath providing the vast majority of the same level of functionality. (I'm actually considering sticking with an older version of IKVM for this reason - file size matters when you're building an installer that's being shipped over the network). It's apparent in the fact that Classpath has a clean API for targeting multiple VMs including VMs for which native code is unnecessary, where the JDK's VM interface is internal and relies heavily on native code.

It seems to me that there would be a lot of value in approaching an OpenJDK / Classpath merge in the same way the libgcj and Kaffe merges were approached: compare the code on a class-by-class basis, bring in whichever implementation is best, and change it if necessary to account for things the other implementation did better. My gut instinct says a lot more Classpath code would survive that process than is surviving today in IcedTea - and the end result would be significantly smaller, cleaner, faster and bug-free-er.

I don't know whether the copyright ownership issues have been resolved yet to make it possible to actually pull OpenJDK code directly into Classpath though.

Regardless of what approach ends up being taken, though, it's good to see work happening on Classpath again, and a new release being contemplated. I guess it means I need to get those darn Japi runs happening again though!

Thanks

By Roman Kennke (Email) at 2007/09/21 09:10

Thanks for motivating :-) I think what's happening right now is that Classpath and it's community find a new place in the Java universe. There are 'market segments' for which OpenJDK just isn't the right answer. I'm thinking about the embedded market and such. You just can't afford the bloat that is OpenJDK.

I think IcedTea is relatively active, at least I see a bunch of commit mails each day. People just don't blog about it that much.

I'm hoping that it will be possible let code flow from one base into the other. As far as I know, the legal issues aren't resolved yet. Maybe it'd be a good idea to set up a non-FSF project which is basically Classpath and merges OpenJDK code in for fixes and features. Somewhat the opposite of IcedTea.

Re: The reinvigoration of Classpath?

By David Gilbert (Email) at 2007/09/21 09:19

For me, getting a trivial bug fix into OpenJDK is something like compiling and running "Hello World" in a new programming language - it's a valuable first step in spite of its insignificance.

Regarding GNU Classpath, I think the project is going to struggle, simply because a big slice of its audience has disappeared. Those people that want/need Free Java (including me) can get that in OpenJDK (IcedTea in the interim). Why reimplement any more?

It *is* a shame that GNU Classpath is fading, because it was a wildly fun and productive project to work on...but on the whole, I think we are better off now that OpenJDK is here.

Re: The reinvigoration of Classpath?

By Jeroen Frijters at 2007/09/21 09:53

I've spent a lot of time in both code bases and I can say without a shadow of a doubt that OpenJDK is of much higher quality than GNU Classpath.

All the open source rethoric in the world can't compete with solid engineering practices.

Good to know

By Stuart at 2007/09/21 10:39

Thanks, Jeroen, that's good to know. I think most of my opinion on the quality of the JDK codebase was formed when all we had was what we could deduce from the public-facing parts of the binary blob; it was easy to make broad assumptions about the quality from the apparent "bloat" and the very obvious API problems that showed up in trying to get good Japi coverage.

It's good to hear that the code is on the whole good quality despite those warts.

I'm still curious as to how it is that Classpath was able to get so close to doing the same amount of stuff, in a fraction of the amount of code.

In theory ...

By Dalibor Topic at 2007/09/21 12:07

a merge would be great. In practice, OpenJDK already works well enough, euphemistically spoken, so the motivation to go over it class by class is lower than it would be if it was another partial implementation, where the pay off is more immediate.

That said, OpenJDK can learn many small things from Classpath, definitely.

Not quality, but resources

By neugens (Email) at 2007/09/21 17:01

I don't agree with Jeroen about the rethoric argument.

The JDK is of superior quality because there is testing, resources, the API is designed by the engineers that work on it full time, and have access to all the documentation.

We had to reverse engineer almost all the classes, trying to realize how most of these had to behave, and doing all that only with the help of mauve and in our free time. It's not fair to call it "rethoric". Given the resources we had, Classpath shows that the Free Software is the way to go, if backed up by a company, like now is the JDK, possibilities are endless. Classpath will die? No problem, we have arleady hit our goal.

RE: Not quality, but resources

By Jeroen Frijters at 2007/09/22 06:18

Mario, I don't think we disagree that much.

I think we can be rightfully proud of what we accomplished with GNU Classpath, but that pride shouldn't cloud our judgement and still allow us to see that OpenJDK is better (as you acknoledge).

What I meant with the "rethoric" remark (which maybe was a bit over the top) is simply that there is a tedendency to assume that FOSS automatically means better software, but that, of course isn't true. As you point out, it is likely to be true given two projects with equivalent resources, but it is simply rethoric to say that FOSS is always better.

RE: Good to know

By Jeroen Frijters at 2007/09/22 06:47

I'd like to know more about the size difference as well.

Part of it is surely because GNU Classpath still doesn't implement some parts (even though the API may be there, the backends may not be).

There are also examples where Sun uses (mostly) VM specific optimizations, but they have lots of Java code to deal with that. Two examples that come to mind are: reflection uses only-the-fly code generation and they've got a zillion generated nio Buffer classes for all variations of read-only/read-write/heap/direct and all primitive types.

We need the best of both worlds

By Andrew John Hughes (Email) at 2007/09/24 07:47

First of all, thanks for your post Steve, it's nice to have this kind of objective view of things. I hope things are starting to getting going again, the OpenJDK thing has slowed things down a lot.

I like OpenJDK in that it means we can now have a trustworthy Free Java solution (with the help of IcedTea). However, it's still a pain to get to that stage and it will be nice to see a time when it is packaged with distributions.

IcedTea has done a great job in making what Sun has released usable. However, we're bound to see less innovation there than the little we saw in Classpath because it's larger a job of making sure each drop by Sun works.

For me, OpenJDK is still not a Free software project. It may be able to replace Classpath on technical merits in most arenas (a VM interface being one of the exceptions), but the social side of the project is just not yet there. Whether this means bringing OpenJDK code into the existing Classpath community or migrating the Classpath community over to OpenJDK as developers I don't know but we don't have a perfect solution yet.

Add a comment:

Subject:
Name:
Email:
Url:
Title:	Don't enter anything here if you're a human.
CAPTCHA:	Don't enter anything here if you're a human.
Comment: