Introducing Caciocavallo

A while ago, our (Mario and me) project proposal for the OpenJDK Innovators Challenge has been accepted. Today I’d like to announce the actual project, codenamed Caciocavallo. This project will cover a couple of things:

  • An implementation of the AWT Toolkit interface (java.awt.peer and a bunch of classes in java.awt), that doesn’t make use of Sun internal classes.
  • An implementation of the AWT Toolkit interface that subclasses Sun internal classes and reuses most of the infrastructure. (This is named Caciocavallo-NG)
  • Patches to OpenJDK to enable the above 🙂 Plus better documentation, etc.

The toolkit implementations will be based on the great Escher library. So far we have (somewhat) working prototypes for both the ‘external’ and ‘internal’ implementation (that’s how I call them). Also, I reworked a significant portion of Java2D, to separate SunGraphicsEnvironment and FontManager. So far, the FontManager class was a final class, with most of the platform dependent font stuff in the subclasses of SunGraphicsEnvironment (urgs), and some more platform dependend stuff in FontManager itself (uuuuuurrrgs: look into FontManager.populateFontFileNameMap()). I changed it so that FontManager is an abstract class, with platform specific pieces in subclasses. SunGraphicsEnvironment doesn’t have any font stuff anymore. Works like a charm already.

Until the project is setup within OpenJDK (soon), all the code resides on my server. There’s caciocavallo and caciocavallo-ng (the external and internal toolkit implementation respectively) and a HG patch queue (what a nice feature of HG that is!!) for OpenJDK.

BTW: I spotted a fun part in the affidavit (new word learned) of The Challenge:

I understand and acknowledge and hereby waive and release any and all rights, demands, losses, liabilities, claims and causes of action whatsoever which I may now or hereafter be entitled to assert, including, but not limited to any death, injury, loss of enjoyment or other harm or loss of any nature whatsoever caused by, contributed to, or arising out of any prize awarded to me in this Contest.

I guess this means I can’t sue Sun when I get a heart attack from the price money, or when I don’t enjoy hacking OpenJDK anymore afterwards. Too bad 😉 Ok, now on with hacking (so many things to work on parallel, I need some clones of myself)

Caciocavallo at FOSDEM 2008


About Roman Kennke
JVM Hacker, Principal Software Engineer at Red Hat's OpenJDK team, Shenandoah GC project lead, Java Champion

7 Responses to Introducing Caciocavallo

  1. Lillian says:

    Congrats to both of you! That picture definitely brings back good memories 🙂

  2. David Herron says:

    With fond caciocavallo memories from FOSDEM I’m looking forward to what comes from this.

  3. Pingback: Swing links of the week: April 13, 2008

  4. bjb says:

    Why not plan for the Toolkit to become a true Java SPI ?

    IE, implementation dependent code (including native code !) is kept at SPI implementation side.

    If so, this would open lots of possibility on AWT : ease port, ease maintenance, ease AWT evolution.

  5. roman says:

    bjb: basically, this is the plan. I doubt that this will become an official SPI (official as in publicly documented by the spec), but I hope that it will become a semi-official SPI at least.

  6. Pingback: This note’s for you » Blog Archive » Caciocavallo: Portable GUI backends

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: