This note’s for you

The last couple of days I spent going through the AWT peer interfaces and cleaning them up (get rid of all the duplicate and deprecated stuff there), and have now started to document the stuff. The first results can be found here. For now I only have ButtonPeer to ComponentPeer, but I will add the missing stuff during the next couple of days, and I will also add all other classes that are necessary and/or helpful (like Toolkit, GraphicsEnvironment, and some internal classes).

I’m also very excited about Mario’s work with JOGL and Escher. This is so amazing to see (start) working.

Another day, another non-existent problem solved Seriously, the font problems I’ve seen yesterday have been kindof bad luck. Wrong font has been chosen by the pipeline, one that doesn’t render smooth as bold font. Plus some small problems in OpenJDK and/or FreeType regarding rendering this font, etc. Today I tried the Font2DTest program of OpenJDK and most fonts look just fine:

This is Bitstream Vera plain without anti-aliasing. Pretty smooth. The font we’ve seen yesterday has been FreeSans bold:

Which also looks slightly crappy with OpenJDK’s default pipeline:

BTW, it’s really amazing how well Swing applications already work. There are only very few glitches (no mouse drag yet for example) and performance seems reasonable (not quite on par with the OpenJDK X11, but still). And all this with minimal effort on my side, I really only implemented a handful of primitives and a little infrastructure. Yay OpenJDK Java2D architecture!

Today I finally solved a non-existant problem, and can finally show some stuff from the OpenJDK challenge work:

The demo already works quite well and performance is reasonable. Of course, there are still many quirks and etches, and the fonts look like crap. Not sure yet, why the fonts look so ugly, I have to find this out. This is using OpenJDK rendering pipeline and does all the rendering in pure Java (over Escher).

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)

Today I had problems with my Wordpress installation on my Debian server again. Somehow, somebody managed to get access to my Wordpress install and disable all the plugins, especially the Askimet plugin. Immediately, I got swamped with spam. I suspect that the Wordpress package in Debian stable is not really well maintained and vulnerable, so I upgraded to Wordpress 2.5 by backporting the unstable package. This was a very smooth process.

This is how it should work:

echo "deb-src http://ftp.de.debian.org/debian unstable main" >> /etc/apt/sources.list
apt-get update
apt-get build-dep libphp-phpmailer
apt-get source -b libphp-phpmailer
dpkg -i libphp-phpmailer_1.73-6_all.deb
apt-get build-dep wordpress
apt-get source -b wordpress
dpkg -i wordpress_2.5.0-1_all.deb

Following that, I went to the wp-admin page, performed the DB upgrade and everything was fine. Very smooth. (I did a mysqldump before thought, just to be sure)

Today I discovered to my surprise, that the X peers of OpenJDK also use Swing as painting backend for its widgets (as opposed to the Motif peers that use Motif or Lesstif or whatever). Unfortunately, this doesn’t seem to be done in a very reusable way (==hardcoded in the X peers), as I did with my own Swing peers in GNU Classpath. I mean, it is really nice to have this reusable, because then, implementing a new backend for AWT is basically only implementing the top level components and graphics stack. I wonder, if these could be merged somehow, i.e. the reusability of my Swing peers with the completeness of OpenJDKs X peers. Hmmm, this would have been another nice proposal for the OpenJDK Innovators Challenge….

This year’s FOSDEM has been a great event, as every year. I’ll try to wrap up my personal highlights.

Friday

I arrived in the evening and immediately headed for the Brandweg hacking session and general gathering to the BXL. The waitresses wouldn’t let us go upstairs into our usual location, but when more and more people joined us, they had no choice but open up. I guess they were not really prepared for such an event. In the end they became really nervous that things get out of hand, so we collected money to pay the bill and leave. I went to the hotel then because I was very tired.

Saturday

The keynote talks have been kindof disappointing for me. I couldn’t really relate to the Hollywood and FreeBSD stuff. The patent talk was an interesting update though.

Regarding the various talks I will only mention my personal highlights. All talks have been very cool, but I can’t cover every bit here.

Mark and Mark wrapped up what happened during the last year to GNU Classpath and OpenJDK, and where things are going. GNU Classpath ain’t dead at all,though things slowed down, and OpenJDK is moving towards 100% free software steadily.

Christian Thalinger gave an interesting overview and comparison about the different VM interfaces of GNU Classpath, phoneme and OpenJDK. Especially since I’m porting OpenJDK to Jamaica now.

I was really excited about what Guillaume showed with MIDPath. He did some really amazing work on those little devices, showing off a number of great demos.

My own talk didn’t go that well. I was suffering from a major headache at this time because I didn’t drink anything for the whole day (that always kills me). I think I spoiled the party a little by bashing OpenJDK handling of the community, which probably came around too negative. (Yes, some developers do very good work with handling the community). And to make things worse, my nice demos of OpenJDK-Swing-on-Escher and OpenJDK-Swing-on-GTK crashed because I was trying to run them on a clean OpenJDK, but they require some patches in Swing and AWT. Too bad.

Andrew picked up my own mashup things and introduced Brandweg, a project similar to IcedTea, but in the other direction. (GNU Classpath, patched with OpenJDK stuff where appropriate).

The VM rumble was great, just as last year. Robert gave a good update on JamVM (which goes into a JIT-like direction now), Kaffe collapses to a big shell script that pulls in all the pieces, Hotspot is getting better all the time, and conquering new platforms with Gary’s zero assembler hacks.

In the evening (almost) everybody gathered at the FOSDEM dinner. The food was very good, very expensive and too little for my hunger. Afterwards, a couple of people moved over into a greek(?) bar, where a small but loud YMCA party was going on. Fun, but not good for chatting. I had some nice conversations anyway, geeks are so boring ;-).

Sunday

The first talk I attended on Sunday was Lillian’s and Thomas’ talk about IcedTea. They did some truly amazing stuff, turning OpenJDK into a free software JDK, and plugging the holes with GNU Classpath pieces for the API, NetX as a WebStart replacement and gcjwebplugin/IcedTeaPlugin as browser plugin. Very nice. Thomas also showed some of his work to implement LiveConnect in the IcedTeaPlugin.

The cool stuff section had some amazing projects showing off really cool stuff. Steph showed FBToolkit, a very cool project which aims to provide an alternative AWT toolkit/graphics implementation for framebuffers and other backends. Mario did a very nice presentation about his work on the GConf preferences, Classpath’s Desktop API implementation and about his GStreamer backend for javax.sound, showing off a nice rocking demonstration.  The JNode impressed me very much, despite the technical problems. A whole operating system mostly written in Java (plus some assembler for the very low level device stuff), this is really cool.

Unfortunately I missed the Jalimo talk and everything afterwards, because I had to leave to catch my train. In the train I turned all the fresh inspiration into code and completed a first prototype of the new Escher peers (aka Caciocavallo), which are based on OpenJDK’s architecture for Java2D (SunGraphics2D, SunGraphicsEnvironment, et al). I had a very very first prototype already running before FOSDEM, but this was awefully slow. Now I can already do some Swing stuff at reasonable speed. That’s really amazing (to me).

Yesterday I received a 20$ donation for my old program Xebece, a nice little tool for visualizing large sets of information. That is really nice. It made me hack on it again immediately (you see, I’m completely reward-driven ).

I was really shocked when I looked at all this code. It’s only 3 or 4 years ago when I wrote this, but man, did I write crappy code back than. And I remember I did it with the best effort to actually produce good code. Duh. On the other hand, it’s really amazing what I learned in all this time. Most of this can be credited to my work on GNU Classpath (which I actually started because I wanted Xebece to run on a free Java platform).

There’s still many ideas floating in my head for Xebece, when I find some free time *cough* I gotta implement:

• An abstraction for the tree view, to allow alternative renderers. More specifically, I’d like to re-introduce the hypertree library. The first versions of Xebece (actually, Ontographics back then) where written against this library, but removed in favor of Prefuse because the hyperbolic tree rendering is patented in the US. However, I think it is the superior renderer, it is GPL just like Xebece and I’m a co-maintainer of this project too, so I have more control over the code (yeah yeah). OTOH, Prefuse is some BSD license (the version in Xebece is actually the dreaded 4 clause license with advertising clause which actually makes it non-free, but it seems like they changed it to a free 3-clause BSD lately, together with reworking all of the API to be completely incompatible with my code, hrmpf).
• Throw out the weird text/image blocks on the right pane, and replace it with a simple HTML editor. Same practical purpose, but much more straightforward to use (I hope).
• Allow interconnecting links from one tree node to another (which effectively makes the tree a graph), possibly augmented by special URLs in the HTML pane.
• Speaking of URLs, using a HTML editor would also allow external web URLs in the information panel on the right.
• Easy to use Applet export which would create an applet bundle out of the current project for simple uploading on a webserver.

Phew, quite a lot of ideas. And most of them were floating around for 2 years already and I never got around to implement them. Let’s see how far I get now.

.. I got linked on the java.net frontpage. Wow. And somebody has linked a whole bunch of older posts into community.java.net/openjdk and even bother to make a small icon for me. Am I famous now? Ok, seriously. I enjoyed all those good comments, as well as one really moron-ish^Whumorous comment (duh. I have a real life, man! but I really shouldn’t answer to such stupidity.). The general consensus seems to be that an open Mercurial repo would help alot. That is my opinion too. I’m sure this is beeing worked on. From this point it has to be seen if it is worth to setup some processes to make code flowing from the community to OpenJDK less painful.

(BTW, the best comment I received offline via private email from Christopher Oliver - sorry Chris I gotta quote that - “Perhaps, if you worked for Sun that would remove a lot of those stumbling blocks. ” Hehe, right. That would probably help me, but not the community at large. But yeah, this is a little out of context and I probably shouldn’t quote from private email anyway.)

Back to real life, today I hacked and cleaned up Escher’s image handling (still no idea about XYPixmaps though) and implemented VolatileImage and DataBuffer on Pixmap and ZPixmap (server vs. client side images in X, respectively). This is an important step forward for the Escher peers. Now I only need to think up some cool tricks to do that for BITMASK and TRANSLUCENT VolatileImages and BufferedImages too, which ain’t that easy because (plain) X doesn’t support translucency for itself.

It is such a ridiculous pain to get a patch into OpenJDK, I get the feeling that this is not the kind of project, I would feel comfortable with. Both of the above linked patches have been rather trivial. Davids patch even came with a testcase. And still it has to go through a week-long process before it can show up in the build. This will scare off most voluntary contributors quickly I guess.

Now the thing is, I have to deal with OpenJDK as part of my job. So I will have to do some tweaks here and there. What I am going to do is, upload my patches somewhere, post a link to them so the Sun dudes can pick it up if they like, or not if they don’t. But I certainly won’t jump through their hoops only to get my code in. I will do my job, but I won’t spend my free time to implement some encumbrance or whatever. I have more important things to do, like hacking on GNU Classpath, Escher, Xebece or Hypertree. That is, if I actually find some free time besides the baby and family.

Update: I think a good chance to both serve the community and keep things stable would be to open up the repositories a little more. If non Sun contributors could work freely, for example in an external project like IcedTea, their patches could probably be fed back into Sun’s internal reviewing system in a streamlined, automatic or semi-automatic fashion. It would be even better if the community could be included into this reviewing system.

There’s a lot to be done and I’m sure a lot will be done. For now I’ll take care for my own little projects.