Recently Classpath’s generics branch was merged to be the main line. This means all future Classpath releases will use generics, and now we’re free to use other Java 5 features in the Classpath source.

When we started the generics branch we made a conscious decision to do a “shallow” translation to generics — we rewrote method signatures and visible field signatures, but not the bodies of methods. This was done so that we could more easily merge changes on the trunk to the generics branch, a smart decision considering that the generics branch lived for two years.

This weekend I spent some time adding generics in a deep way, that is, modifying the bodies of methods to properly use generics, and attempting to remove all the warnings related to raw types, unchecked casts, etc. Aside from random warning removal, I had a specific question in mind: how much reliability do generics add?

I completely converted about 5 components (meaning some core package plus all its support code). In all of this I found 2 actual bugs. (Also I once found a bug in imageio on the generics branch during a shallow conversion, bringing the known total of bugs found by generics to 3.)

In one case we were making an invalid assumption about the actual return type of Collections.toArray() (and, btw, this particular API can only be truly fixed by reified generics; in a sense we were lucky to catch this bug).

In another case a protocol implementation had made an incorrect assumption about the types of the contents of a collection it returned.

I have to say I was very surprised by this result. Generics are somewhat tricky to use, add a lot of verbiage to the source (especially since Java doesn’t yet have C#’s var, aka C++’s auto type inference feature), and now, apparently, don’t really catch very many bugs.

There are a couple other theories to consider other than “generics aren’t worth it”.

One is that Classpath, being a core library, is unusually less susceptible to bugs of this kind than other Java programs. I don’t consider this very likely, but more experience with other programs would be useful.

Another is that the Classpath development process is unusually good and catches more bugs than normal. This would be nice if it were true, but I doubt this is very likely either.

Finally, one could argue that catching even a small number of bugs in legacy code is good, and that the real worth of generics comes when writing new code.

I’ll collect more data as we convert more of Classpath to use generics deeply. I’m curious to know whether other folks have had more positive experiences during conversion, or whether there’s something I’m missing about all this. At the moment generics appear to be “nice to have” but hardly worth the substantial upgrade effort across the toolchain and the large body of existing Java code…

Today I checked out the newly-free javac and built it with (heresy?) Eclipse. Aside from waiting for it to build (this machine is a bit over-taxed at the moment), this only took a few minutes to set up.

I read through it a little bit, but not extensively. Overall it seems well done… easy to read, has a reasonable amount of javadoc, the big-picture layout is easy to follow, it uses generics throughout, etc.

I’m not sure what I was expecting really. Something more painful I suppose; I think I assume that all programs will be a pain to set up and build. It helps, of course, that Andrew and others got there earlier and put some needed support code into Classpath 🙂

It doesn’t look outrageously hard to add code to support using javac as a front end to gcj, the way we’re using ecj right now.

I was out of town on my honeymoon (it was excellent, thank you very much) when Sun announced their choice of license for open source — or should I say free software? — Java. A few people have written to ask me my opinion on the topic, and rather more people have asked about the relevance of this change for Fedora, for gcj, and for Classpath. So, I’ve spent some time writing a post detailing my thoughts.

First Thoughts

This news is wonderful! It is the culmination of a 10 year dream to have a free software Java implementation, and not only that, it is the best possible way to to achieve the goal: having the reference implementation be the open implementation.

I’m also delighted by Sun’s choice of licenses.

Furthermore Sun is executing well on their promises. The people I’ve talked to have responded well to feedback (for instance on fixing some details in the contributor agreement) and they even were clear about the distinction between free software and open source.

I’m very optimistic that they will continue in this vein.

What about Fedora?

Naturally folks out there were eager to see OpenJDK in Fedora immediately. These initial responses are always a bit funny because the posters seem to send their messages before getting to the part of the press release explaining that not all the software is publicly available yet. Silly.

Still, the instinct is the right one. In my opinion, OpenJDK is the way to go. When we can build a complete implementation, we ought to package it and make it the default JVM on Fedora.

I think this won’t happen until at least Fedora Core 8.

Meanwhile, for Fedora Core 7 we should ship the new ecj-based gcj with support for all the new 1.5 features. This requires a bit more work, and perhaps a backport, depending on the base gcc chosen for the OS.

One issue down the road for OpenJDK adoption on Fedora is that it does not have a PPC port. Community hackers, please write this.

Oh, and when we ship OpenJDK, someone should take a good look at shipping NetBeans as well. Eclipse is wonderful and in some ways definitely better than NetBeans, but there are areas where NetBeans is superior as well.

What about Classpath?

I think our experience over the years has shown that every time we merged code bases, we gained. We gained developers, we gained quality, we gained completeness. In other words, it is better to work on a single good implementation than multiple competing implementations. (I don’t think this is a universal law, but it is true in the specific case of Java class libraries: an program where the result is relatively well-defined).

So, it is hard for me to see what role Classpath will play in the future. OpenJDK’s library will have the same license and will be the reference implementation. That argues strongly for moving Classpath development work time to OpenJDK hacking instead. (At least assuming contributor agreement stuff is cleared up … a detail.)

Classpath does have some code that the JDK does not. For instance we have some interesting AWT peers, we have a GConf back end for prefs, our HTML implementation is better, and a few other things. For the peers I think we could do separate releases (contributing these to OpenJDK is difficult or impossible — it may violate the FSF’s charter). For “pure library” bits, I’m not sure what to do 🙁

What about GCJ?

For many cases I think it will be preferable to switch entirely to OpenJDK, and not use GCJ at all.

Don’t get me wrong — GCJ is cool, and I’m proud of what we’ve done. I think we’ve solved some hard problems in creative ways. But, for many uses of Java, compatibility is the name of the game, and it is simpler to get this using the reference platform.

I think there are still areas where GCJ makes a lot of sense — embedded systems and the various platforms where there is a GCJ port but no other VM. I don’t expect it will die, but I do expect that the effort going into it will subside quite a bit. That will matter less, though, since it will be somewhat simpler for GCJ to keep pace now, since the libraries will need much less work than in the past.

Don’t Panic

Naturally this is all still contingent on things working out as they should. I’m not worried about this, and I don’t think you should worry either.

Also some patience is required. We’ll know much more in 6 months.

FOSDEM

Some folks from Sun will be at FOSDEM this year to talk about OpenJDK. And, of course, the usual Classpath and GCJ contingent will be there. I hope to see you there.