What’s Sun’s interest in OpenJDK?

In response to a comment on one of my previous posts, I’d like to elaborate and speculate on this question a little.

I agree that Sun’s first interest is money. Sure, they can tell us they are doing it for idealistic reasons, or practical reasons, but you know, it’s a shareholder company and shareholder companies are bound to be after the money as their first interest. No arguing about that. However, I don’t think that Sun is only doing all this as marketing move to get some hype. This would be very short-sighted and narrow-minded.

So you might ask, we are living in a free market, and everybody’s playing against each other, where’s the money for Sun in opening up Solaris, Netbeans and Java’s code, effectively giving all the competitors an advantage, and even effectively giving them their millions of work-hours (== money) that they put in these products, if it’s not the marketing hype that follows the announcements? Well, Simon Phipps explained this nicely at FOSDEM, I can’t repeat his words so I’ll try it with my own.

Let’s take for example aicas, a small company producing a realtime capable VM (the one I’m working for). In the past, we were building around GNU Classpath as a class library for the VM, and will continue to use it for a couple of packages. You’d think that it is kindof stupid for Sun to open up their code, so that competitors like us can leverage their work and manpower and code into our own VM (Sun also has an embedded – maybe even realtime, dunno – track of their own VM). But have a look at the big picture. This move effectively helps to join forces. Sun is practically helping many small companies and VM vendors by opening up their complete Java stack. These many small vendors in turn are then able to move forward with their specific technology, instead of reimplementing the wheel again and again. It creates a level playing ground for all of them. This has the seemingly paradox effect that it stimulates competition at a completely different (and IMO more fair) level, and that on the other hand all these parties can join forces in drive Java itself forward, possibly breaking new ground for Java, which Sun alone wouldn’t be able (and has no interest in) to do (like, for example, realtime applications). This of course helps everybody involved.

This is of course very visionary and nobody really knows how it can and will work out. But in order to even have a chance to play out well, it is vitally important that Sun not only takes this as a marketing action, because it would then miss all the important advantages that this move could have. It is really important that Sun manages to create a healthy community, that it works together with the community rather than only publishing some code drops now and then (like it seems to happen in another popular free JDK project). Then, and only then, everybody can benefit. This is the reason why I’m complaining, not because I’m a Linux zealot GPL whining hippie 😉


Nuclear plants

As you might have noticed or not, there’s currently a hot discussion in Germany about Vattenfall and its problems with nuclear plants. My opinion on this topic is that they should be taken off the net as soon as possible, for the following logical reasons:

  1. They are inherently dangerous. No matter how secure the technology is, the human factor cannot be overcome. The recent events clearly demonstrate this. There might indeed be very little risk in modern plants. But 1. many plants aren’t modern anymore, 2. in case of a GAU, the damage is catastropic. The equation is (likelyhood of event) * (possible damage) and the outcome is pretty high for my taste.
  2. As the current events in Japan shows, natural catastrophes like earthquakes can severly damage the plant.
  3. They are nuclear bombs standing all around the place. I think, terrorists don’t need to get hold of nukes themselves. If they manage to fly a plane (like 9-11) into a plant they have more or less the same GAU effect.

It is funny (in a very dark way) how the officials of Vattenfall manage/try to twist the events so that they actually prove how safe all these plants are (like, it all proves how the technology can account for human failure and such). I strongly believe that ecologic power (especially bio mass energy) sources can completely replace nuclear plants. (In germany, ecologic power providers, like Lichtblick, already offer energy at the same or lower price than conventional energy for example).

Speaking of nuclear plants, there’s an interesting and impressive photo series from a woman who drove to Tschernobyl with a motorcycle here. Be sure to have a look.


.. 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.

Java Enums

Two interesting insights about Java enums that I found today that are not obvious and might be useful for others.

Enums with methods

Sometimes it can be useful to associate certain behaviour to an enum constant. For example, today I wrote an enum that represents the different types of images of the X protocol:

public enum Format {

Later in the protocol implementation I needed the IDs that are associated with each format. My first implementation used a switch statement (see below) to determine the ID. However, there’s a more elegant way to implement this:

public static enum Format {

  BITMAP   { public int id() { return 0; } },
  XYPIXMAP { public int id() { return 1; } },
  ZPIXMAP  { public int id() { return 2; } };

  public abstract int id ();


Ok, you can say that I could have used the ordinal() method of the enum. However, the above is more powerful. You can implement arbitrarily complex methods (with parameters etc) in an enum. I would tend to be concise though, and not implement anything that doesn’t fit on one or two lines.

Enums in switch statements

Well, this is of course a central design aspect of enums. I found it a little difficult though, until I found the correct syntax. What I did is that:

switch (format) {

  case Image.Format.BITMAP: // blah
  case Image.Format.XYPIXMAP: // blah
  case Image.Format.ZPIXMAP // blah


Looks like an obvious approach right? Well the compiler didn’t like it. It took me a while and some hints by friends on IRC to find out what’s correct:

switch (format) {

  case BITMAP: // blah
  case XYPIXMAP: // blah
  case ZPIXMAP: // blah


The case labels ‘inherit’ the type from the object passed into the switch statement. Well, now that I think about it it is obvious, because it doesn’t make much sense to switch over something like:

switch (format) {

  case Image.Format.BITMAP: // blah
  case Image.Format.XYPIXMAP: // blah
  case Image.Format.ZPIXMAP // blah
  case  Something.OTHER: // Bad!


So it makes sense for the compiler to not accept such code in the first place. I still had some trouble and maybe this post saves somebody some time.


Right now I’m trying to beef up Escher’s PutImage and GetImage implementation. The specification says there are two formats for pixel data transfers. XYPixmap and ZPixmap. However, it is very silent about the actual format of the two. ZPixmap was relatively simple to ‘reverse-engineer’, it is basically a standard pixmap as we all know it. The XYPixmap however is quite different and a real puzzle. I can’t seem to find any documentation on it, and my reverse engineering attempts have not been very sucessful. Does anyone know about this format? Or have a pointer to some documentation? As a last resort, I could fall back to reading the XLib code, but for now I’ll try to get further with my reverse engineering attempts.

Contributing to OpenJDK, no thanks

Late Update (January 2009): I see that this particular post is still very popular in search results and server statistics. Probably it is linked on various sites. I want to say that Sun took my criticism very serious and most things changed alot, and all other things is beeing worked on. So please read the following original post with that in mind. I’m a rather happy OpenJDK contributor now.

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.

Swing on GTK peers again

The last couple of days I came back to coding again. I polished up the GTK peers, fixing and optimizing copyArea() and drawImage(),  and they seem to work smoothly with OpenJDK and its Swing now. It has its glitches still (see texture and gradients) but is already looking very good, seeing how little work I actually had to put into this.

OpenJDK Swing on GTK peers