TrueType fonts on Jamaica+VxWorks+WindML

After some days of feverish hacking, I’m very proud to show for the first time TrueType font support on JamaicaVM, running on a VxWorks system using the WindML graphics backend:

Hello World 1 Hello World 2

This doesn’t look very spectacular, but there’s a whole lot of things here that I’m very proud of. First of all, it’s the first time that JamaicaVM can support TrueType at all, which is quite amazing. This also showcases all the work that Mario and me put into the refactoring of the FontManager API (which is finally on its way into OpenJDK mainline btw). This is using an alternative FontManager that makes it possible to embed the .ttf files into the application binary, and – in theory – even load them from ROM. This is cool on systems that don’t even have a filesystem. Now on to image blitting and volatile image support, yay!

About the financial crisis

The events at international stock markets are quite interesting the last week or two. My personal interpretation is that this is the proof that an economy that is built on illusions (of infinite growth) and on bank credits cannot be sustainable. I really hope that this goes down big time, and something new and better will emerge. I’m also in big favor of the We Deserve It Dividend, this solution is too good, it can not fail.

The Big FontManager Refactoring

One of the biggest tasks in the Caciocavallo project is the refactoring of the FontManager class. In the current OpenJDK code, this class is huge kitchen sink for all kinds of things that have no other place (or so it seems): it’s a final class with all static methods, with platform independent font code, utility functions, platform dependend code (windows and solaris mixed), fontconfig code, all nicely packaged in one big class. To make it even worse, there’s a bunch of similar font related methods in SunGraphicsEnvironment. My favorite comment in FontManager that says it all is this:

/* This is implemented only on windows and is called from code that
* executes only on windows. This isn't pretty but its not a precedent
* in this file. This very probably should be cleaned up at some point.

Ok, the latter is what we did in the end 🙂

The process of refactoring was a very interesting one, I won’t go into the details. We went to several iterations (I think around 7 by now), and after each one we had a quite large change already. During all the iterations, we kept moving code around, and for the first couple of iterations the mess didn’t seem to get better. But what we have now almost makes me proud. What we have now is this:

  • FontManager: Is an interface now. It ended up surprisingly small. This is the main interface to which the API classes talk to (java.awt.Font for example).
  • FontManagerForSGE: A subinterface of FontManager. It adds a couple of methods that are used by SunGraphicsEnvironment. Graphics backends that are based on SGE need to implement this for fonts, other backends (based on plain GraphicsEnvironment) only need the plain FontManager.
  • SunFontManager: An abstract base implementation of FontManagerForSGE. (Right now this class is called FontManagerBase, but I’d like to rename it before pushing to OpenJDK.) It has all the platform independent code that serve as a basis for the platform specific implementations.
  • X11FontManager, Win32FontManager: Subclasses of SunFontManager for the respective platforms.
  • FontManagerFactory: A factory to create a fontmanager that is suitable for the target platform.
  • FontConfigManager: The fontconfig related code of the original FontManager went there.
  • SunGraphicsEnvironment: has no font related code anymore. Everything is delegated to FontManagerForSGE now.
  • FontUtilities: A couple of utility methods went here.

The scope of this change is quite huge, I don’t envy the guy who eventually will have to review it :-/ OTOH, I really would like to get this into OpenJDK as soon as possible, because maintaining this big change and keeping in sync with upstream is a nightmare. When everything goes as planned, it should be possible to implement a completely different font backend (i.e. based on GNU Classpath’s 100% Java fonts) based on this internal API. Yay!

For now, you could compare the old and new version of and see what looks better 🙂

OpenJDK Java2D on VxWorks/WindML

The best moment when implementing the graphics stack on a new platform is when it first comes alive. This is nicely captured in this screenshot:

WindML graphics on Jamaica/OpenJDK

This probably doesn’t say much to anybody else than me though, but I think it is beautiful 😉 This is the first little step of the VxWorks/WindML J2D pipeline on VxWorks/WindML, using Jamaica together with OpenJDK. There’s a whole lot of things required to make that work: our complete work on Caciocavallo, fixes all over the place to make the VxWorks toolchain happy, lots of workarounds and hacks that I’ll have to clean up now (ugh), etc, etc.