Happy Birthday Alba

Today at 4:20am my daughter Alba was born at our home. She and Madeleine are both feeling perfectly fine, we had no complications at all. Welcome on earth little girl. Oh man, she is so beautiful I think I’ve fallen in love 🙂

 

Advertisements

OpenJDK Swing on Gtk peers

Against all odds, I got the first bits of OpenJDK’s Swing working on top of GNU Classpath’s GTK peers quite quickly.

OpenJDK Swing on GTK peers

Of course, this is very very rough around the edges. It crashes in various places. But it looks like fixing this will make the GTK peers much better I suppose. Ah, and this dreaded locking is haunting me again :-/

GTK peers on OpenJDK

With surprisingly little change on OpenJDK code itself, and some tweaks in the GTK peers (to account for some new methods in the peer interfaces) I was able to get the Classpath AWT demo running quite nicely on with GTK peers on OpenJDK class library with JamaicaVM:

GTK peers on OpenJDK on Jamaica

Now on to figuring out how to do similar with the graphics stack. This will be a harder battle I suppose.

Jamaica/OpenJDK milestone

Today I’ve got the Jamaica/OpenJDK integration far enough so that Jamaica completely builds itself. That means that not only a simple HelloWorld is working, but also more complex programs like the Jamaica Builder, Compiler and Profiler. This is a very significant milestone IMO.

The next steps are (roughly but not necessarily in this order):

  • Hack the AWT to get Classpath’s GTK peers and Jamaica’s various AWT peers working with OpenJDK. This is going to be an interesting lesson and likely involves patching OpenJDK with Classpath classes, because of the way fonts and images are implemented. Also, it seems that Swing relies on some implementation internals of AWT (again, mostly in the areas of fonts), which will be an interesting challenge to solve.
  • Pull in more native implementations for the currently stubbed pieces, most importantly in java.net and java.nio.
  • Port the thing to VxWorks, Windows CE and OS9 (as well as probably some other target platforms). This actually looks like the easy part, because so far the VM interface seems to map quite well to Jamaica’s target native layer and it looks like we could reuse this even.

Jamaica goes OpenJDK

The last couple of days, my collegue Stefan Gabriel and myself worked hard to intergrate OpenJDK into Jamaica. We use all of the OpenJDK classes now, together with some pieces from IcedTea to fill the gaps. Then we ported/implemented some native pieces in java.io, java.util, java.security, sun.misc and sun.reflect (we don’t use java.lang from OpenJDK) and today we were able to run the first bunch of programs (e.g. the Jamaica builder) with the internal VM (the one that is used to bootstrap most of Jamaica). That was faster than I expected. Yay!

On the other side it was a strange feeling to rm -rf most the code that I spent so much time implementing. But I think in the long run this is the right decision, because it allows us (and I think other VM hackers agree) to focus more on innovation in VM technology rather than bug hunting in the class libraries. And it will take quite some time before we will let loose of all of the Classpath code. Especially in the areas of AWT and Swing I can’t see this until the encumbrances are solved, and some pluggability extensions are brought into OpenJDK (I’m thinking of font and image handling mainly, both of which seem quite hard-wired in OpenJDK).

These days

.. I’m working on a couple of things in parallel:

On one front I’m trying to provide a replacement for the graphics rasterizer in OpenJDK. As far as I can see to this point, the rasterizer I implemented for GNU Classpath should be fine for a start. I offered this to OpenJDK, but there seem to be a couple of legal and organizational hurdles to take. I am discussing how to best solve these issues and move forward with the code. It looks like going through the copyright grantback procedure with the FSF for the code in question is hard to avoid. In the meantime, Jim from the Java2D team has factored out a preliminary interface for the rasterizer, and Mark Reinhold offered to provide early read-only VCS access to the Java2D workspace. Thanks!

Then I am working on integrating the OpenJDK class library into the JamaicaVM. It turned out that the package-after-package approach is much more painful than expected, due to massivly intertwined dependencies. I even spotted a couple of places where private methods in ‘alien’ packages are called via reflection (urgs). I wonder how that went through QA, and I wonder what happens when one such method changes… Anyway, with the release of IcedTea I switched to importing all classes at once, with the help of the IcedTea classes this was surprisingly painless. Now I’m working with my collegues to get the native things done. So far we found that they even have some kind of VM/native interface in place, at least for the classes that I looked at so far. Basically, platform dependend syscalls are abstracted out as JVM_* functions. I hope to get a HelloWorld running this week.

Related to the OpenJDK/JamaicaVM porting work, I am working to get the Classpath GTK peers, and the other AWT backends in Jamaica to work with the JDK. The biggest problem here seem to be the differences in Image and Font handling, which are abstracted out in a backend-independent way in GNU Classpath, but seem to be implemented rather monolithically in OpenJDK. Dunno how to solve that. It might be possible to use the OpenJDK implementations when the encumbered pieces in the font and graphics rasterizer are solved. So far I think we have to go with a bunch of GNU Classpath classes in java.awt.***.

IcedTea

It seems to be good news day today, IcedTea is going public. This has a couple of interesting consequences:

  • It allows to build and bootstrap OpenJDK without any binary plugs. The disadvantage here is that the encumbered functionality isn’t available right now.
  • Distros that value freedom like Fedora and Debian can package this and include it in their main repositories.
  • People from outside the OpenJDK (especially but not limited to GNU Classpath) can play with the OpenJDK code without the need to go through the contribution process (which seems to be in a flux now and for some time beeing I guess).
  • The encumbered ‘interface’ is separated out nicely as stubs. This is much easier than going through the OpenJDK sources to find the necessary classes and methods. These ‘only’ have to be implemented then. I will have a look at how my rasterizer fits in there.
  • It kicks Sun (and the community) in the buttock to get their contribution process clean and lean, and to get the encumbrances fixed, otherwise they risk the community going to IcedTea instead of OpenJDK.