The reinvigoration of Classpath?
(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 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!