Please help get my son’s school class get a van

Today I have a somewhat unusual request to you: I need your vote to help get my son’s school class get a van. Let me explain. My son attends a local Montessori school in Ettenheim (Freiburg area in Germany). A local bank is doing a contest for all sorts of local associations to win a van (actually, 8 of them). All of the participating associations are asked to make a short video clip that shows why they need one. And since my son’s school class could really use such a van as sort of school bus or general purpose transportation tool, they made a short video clip. The video clip was made by the students themselves, and I think it turned out really great. The selection of the winners goes in 3 phases: there were 80 participating associations, in the first round 50 were selected by voting (we already passed that), in the next round the top 25 of those 50 are selected by voting again (that’s what I’m gonna ask you about) and finally, 8 of those 25 are selected by a jury. We need to get into that last round now. What can you do? Simply follow this link and click on the star. No registration required. You only need to fill in a captcha and copy+paste some crap in order to prove that you’re human. If you do this: THANK YOU! It’s a great help!

Update: If you already voted yesterday, you can vote again (everybody can vote once per day, up to July 8th)!

Thermostat 0.3 released

The Thermostat team (Jon, Omair, Mario and myself) are proud to announce Thermostat 0.3, codenamed ‘Not Yet’ (yeah yeah, I know). (For those who don’t know yet, Thermostat is a next generation and free/open source monitoring and diagnosing tool for OpenJDK.)

The major new feature is the support for creating and analysing memory by creating a heapdump and browsing a histogram of objects in memory. Additional features include a kill switch, using which you can terminate a running process (for example if it grossly misbehaves), a new Look and Feel (named Dolphin, made to look similar to Gnome 3’s Adwaita theme), new command line commands to support heap analysis, numerous little UI improvements and bugfixes.

The below screenshot shows the new heap analysis view. It monitors the heap usage of a selected JVM. When you click the big ‘Heap Dump’ button, a heap dump image is created and saved in the MongoDB, it shows up in the list below (you can take and analyze several heapdumps per VM.. they will be listed with the timestamp of their creation). Clicking on the heap dump in that list brings up a histogram view that lists all allocated objects, the number of their instances and the total size of their allocation. This list can be sorted by clicking on the respective table headers. (We are planning several more heap analysis features like searching specific objects and following their paths to GC roots, showing incoming and outgoing references, etc etc, but those will show up in the next release, in about 4 weeks from now.)

Thermostat heap analysis view

This was a fairly important release for us, it was our first milestone release, ready just in time for the Red Hat Summit (Deepak will present Thermostat there). Infact, it is the second milestone, milestone 0 was earlier this year when Jon and Omair showed Thermostat at FOSDEM. We took at lot of care and time to make Thermostat solid and useful, and while it’s not overflowing with features yet, we prepared the ground for a lot of greatness. Eventually, Thermostat will support monitoring remote VMs and whole clusters of VMs, and allow drilling down into problem areas and perform deep and fine grained analysis, utilizing information from the JVM itself as well as from the kernel, the operating system and even from the application server.

Please read the release announcement for more details about this new shiny release of Thermostat!

Journey Through The Past

During the last couple of days, Madeleine and I dedicated for a little adventure, which was to clean up our attic. And what a great journey it’s been. I met old friends that I haven’t seen in ages. I have met dreams that never came true. And things that came true, that I would never have dared to dream of. I met some ghosts of the past. I remembered smells and sounds that I thought long forgotten. Lots and lots of memories of nice people that I have met on my way. I have seen love that’s long gone, and love that somehow never happened. And we cleaned up lots of garbage and dirt. Oh boy, loads of garbage and dirt.

The above pictures were made in April 1999. A friend of mine made this picture during a short trip to the Baltic Sea. This was just days before my life would change forever. It was a very happy time. A few days later I would meet Madeleine for the first time. Had I known what sort of adventure I was heading into… I would do all of it again 🙂 She turned my life upside down, a few months later I would move in with her in Freiburg, say goodbye to many of my old friends for the last time (many of them I never met again), and it’s been my best decision ever.

Thermostat goes to Red Hat Summit & JavaOne 2012

Last week, we were happy to receive notification that our (Mario & me) proposal for a presentation about Thermostat at JavaOne 2012 has been accepted! Thermostat is the project that both of us have been heavily involved with during the last 4-5 months (having joined Jon & Omair in February who have been involved much longer and deeper). It’s a next generation monitoring, diagnosing, profiling and controlling solution for OpenJDK. Just now we are adding heap analysis support and make Thermostat ready for its first milestone release at the end of this week, just in time for Deepak’s show at the Red Hat Summit in Boston. The second milestone release is planned to be ready roughly 3 months later, just before JavaOne. (Yes, we invented a new development cycle: Conference Driven Release Management 🙂 ) Hope to see lots of folks there!

Gnome3 usability

I have been, and still am, quite a fan of Gnome. I followed the development of Gnome3 and was relatively pleased when it came out, despite all the bashing. I even find some workflows sorely lacking when switching to other desktops, which is a good sign (for Gnome). It has its rough edges of course, and I hoped they would be ironed out, but I get to think that this might never happen, because some of the things seem to be intentional. Let me list a few of the things that I am most concerned about:
– The timezone-aware clock. I loved this thingy in Gnome2, I would add any location I want, and the clock would show me the time in those places in the popup view. Since I am working with heavily distributed team, this is an extremely useful feature. The clock in Gnome3 instead is very basic. I have seen a discussion somewhere to re-introduce the timezone aware clock back into Gnome3, but apparently it never happened. And doesn’t have anything like that either.
– The hopping notification icons. Unless you are very good with the mouse, it becomes a little bit of a chase to click one of those notification icons in the lower right corner. Why the hell do the need to show a name in the taskbar, and move around while you hover over them??? This is so usability-backwards! Moving things are always a bit of a double edged sword in any GUI. Yes, movements *can* be a very useful visual cue to something happening, but needs to be implemented with great care to not end up being totally confusing. In this particular case I simply don’t get it: why not simply show the icons and only show the ‘name’ (or whatever, sometimes it’s really just some crappy variable name or such) in a tooltip when hovering over it?? There is completely no good reason to shuffle those icons around!
– Epiphany’s new fullscreen mode. The idea is SO good!! But the implementation is so far off, I cannot believe it. First: once maximized there is *NO* way to unmaximize it. I mean, yeah, ALT+F5. After having looked it up in the *web*. Similar for *CLOSING* the frakking browser window. It requires to do 2 mouse moves and 2 clicks. Not to speak of the initial confusion of the close button being replaces by a menu, that simply should not be there. Yeah, CTRL+W. I know. It seems like one half of Gnome devs target idiots who need huge title bars in order to not miss them, and the other half targets superusers who never use the mouse and know gazillions of shortcuts. This is just wrong.
– Since Gnome 3.4 some applications seem to use a new theme with slick scrollbars and stuff, while the other half uses a different theme. I guess it’s because of GTK2 vs. GTK3 dichotomy, but why?? Why not make them look the same until every major app is switched to GTK3?? Now the whole experience is totally inconsistent. I hated this when it happened with Ubuntu’s new scrollbar (and the new Gnome3.4 scrollbar is only slightly better… requires mouse-superskills) now Gnome upstream repeats the same mess.
– For some unknown reason, Evolution becomes more and more broken with every release. In Gnome3.2, it would freeze every now and then when I enabled spam filtering. Now it freezes whenever the computer comes back from suspend, which is the new OFF. (Ok, it doesn’t strictly freeze, it just doesn’t seem to be able to connect to any network.) Fail. Ah, and it manages to always come up on the wrong screen.

I find the state of Gnome quite sad. On one side I really like many of the ideas. On the other side, it really feels a bit like 1998 in many respects. And this is not because of needing to re-learn new concepts, I actually like to try and learn new ways of work. It is really because some things are made unnecessarily hard, for no apparent reason. Or buggy. Or both. I really wish the that those issues get ironed out over time, because I do like Gnome and the underlying ideas.

How to use Cacio-tta with FEST for Java GUI testing

Now that Cacio is finally released and promoted to Maven central repositories, I want to provide you a quick HOWTO about testing user interfaces.

For writing GUI tests, I am using FEST. However, one problem with running GUI tests is that they need to create windows, grab keyboard focus, and do all sorts of interaction with the screen. This has several disadvantages:

  • When running on a developer machine, it requires to not touch anything while running the test suite, otherwise tests may fail or get blocked, e.g. because keyboard focus cannot be acquired or a test window suddenly goes into the background when it should not, etc. This can be quite annoying, especially with large test suites.
  • When running on a Unix-based continuous integration server, it’s possible to utilize xvfb driver to create a virtual framebuffer, but I still often noticed problems that seem to come from asynchronous behaviour of the X architecture. For example, a test would draw a border in RED, and when checking some pixels to be red, they are not. They would only turn red after some unknown time, when the drawing commands have been processed by the X server and graphics card.
  • When running on Windows based CI server, this sort of asynchronous problems don’t occur, but to make up for it, Windows has its own share of problems. First of all, on Windows you need a real screen/graphics card to be present (bad on servers). Even worse, on many Windows servers, you need a user to be logged in, and stay logged in, and the CI server running in that session to be able to access the screen. On other servers, multiple concurrent logons are possible, but not sharing a screen, e.g. when some guy logs into the CI server to do some admin work, it would grab the screen from the CI user, etc. All very complicated and time consuming to setup.

This is where Cacio-tta comes into play. It provides a graphics stack for the Java VM, that is completely independent from the environment. It renders everything into a virtual screen, which is simply a BufferedImage, and is driven solely by java.awt.Robot events. This makes it a perfect fit for GUI testing environments. And using it is very easy. There are two ways do it, and I usually combine them.

1. Include Cacio in your Maven dependencies

Simply add the following in your pom.xml:


2. Run your test with CacioTestRunner

Add the following annotation to your test class:


If you are using FEST and want to take advantage of its additional capabilities (create screenshots on failure, run tests in EDT, etc), use:


instead. Those annotations will make your test run in a Cacio-tta virtual screen environment

3. Optionally, run the whole test suite in Cacio

In some cases, it may be necessary to run the whole test suite in Cacio-tta. In order to do so, add the following to your pom:


This makes sure that Cacio is loaded instead of the default toolkit. This may be necessary, if any of your tests load any AWT, Java2d or Swing class, and are not annotated with the above annotation. This is because Java only allows to set the toolkit once, and it cannot be unloaded or unset. When you load any GUI class before loading the CacioTestRunner, the default toolkit will be loaded, and tests will not run in Cacio.

4. For non-Maven based builds

Of course, Cacio can also be used in non-Maven builds (ant, make, ..). Just download the Cacio sources ( build them, include the JARs in your project somehow, and add the annotations as described above, or set the system properties awt.toolkit, java.awt.graphicsenv and java.awt.headless as described in the Maven snippet above.

Last but not least, if you encounter any problems with Cacio or the above instructions, let us know!

Caciocavallo 1.1 released

I am very proud to announce that after 4 years of development, we publish the first release of Caciocavallo. Due to some funny problems with Maven and my network, it is numbered 1.1.

Cacio started out in 2008 as one of ten projects to take on the OpenJDK Innovators Challenge. This is how it all began, at FOSDEM 2008:

There, Rich Sand and Tom Marble told us about the OpenJDK Innovators Challenge, and Mario brought this fine cheese (on which Steph broke the above knife), and thus the idea to do *something* was born. The original idea was to improve OpenJDK’s GUI APIs implementation (AWT, Java2D and Swing) to make it easier to port the stack to new platforms and plug them in as separate modules. As a proof of concept, we provided a very simple implementation, it was based on Escher if I remember correctly. Back then, Cacio was nominated bronze for the challenge, which made us very proud.

Following that, the focus shifted from fixing OpenJDK to actually porting the GUI stack (although merging the patches into JDK7 would keep us busy for a while to come, I have some special memories of the FontManager in particular). At this time, Cacio evolved from a simple proof of concept implementation into a fully fledged framework for porting Java’s graphics stack. The idea was to make it as easy as possible to do it. And because a large part of that porting work would consist of implementing all those AWT widgets that almost nobody’s actually using (and which are not even available native on many interesting platforms), we thought out a little trick: why not let Swing do all the widget magic in AWT? I.e. from the standpoint of the programmer, you would code AWT, but under the hood, Swing would be used for rendering, event handling, etc. The only thing that a Java GUI port would need to provide is an implementation of Java2D (which is fairly easy to do if you don’t shoot for the fastest ever implementation), and some event handling. Using that, I was able to get a working prototype (working as in, can run Java2Demo) of a DirectFB backend working in 1 week!

After I left aicas and joined Sun in June 2009, things got a bit quiet around Cacio for a while. I was still merging back some of the FontManager fixes into OpenJDK7 mainline, but that was basically it. Until Clemens Eisserer (the guy who took the gold award in the OpenJDK Challenge in 2008 with his XRender work) hit the stage with his Google Summer of Code 2011 proposal to implement a Java GUI layer that would render a Swing application running on the server (in the cloud if you will) directly to a browser, using HTML5. What followed was a time of very intense development, and the outcome was (and still is) absolutely remarkable. We could get a number of Swing applications to run ‘in the cloud’ and talking to browsers running on all sorts of platforms without Java installed locally, including iPad/iPhone, Android phones, embedded devices and of course the usual desktop OSes. It was a huge success which sparked new life in Caciocavallo land.

By this time, I already left Sun and worked for JP Morgan, and there I got really hooked up with test driven development and all other sorts of agile practices. One of the problems that we hit there was running GUI tests on continuous integration servers, because they would either need access to a desktop (when running on a Windows server) and get disturbed whenever somebody logged on the machine, or hit problems with X servers (on Unix systems) due to asynchronicity and other funny stuff. At some point I realized that Cacio could help us here as well, and this gave birth to another side project of Cacio, called Cacio-TTA (pronounced Caciotta which is one special type of Caciocavallo in terms of cheese). This is basically a virtual GUI stack, made for running GUI tests in an isolated environment. It would render to a BufferedImage only, and process events solely through java.awt.Robot. Relatively simple to implement (took me 1 evening, thanks to the already existing Cacio framework), and enourmously useful: each GUI test would now run completely independent from any platform GUI stack, be it X server or Windows desktop or whatever. You can run tests in parallel if you like (just spawn enough JVMs), and every test would get its own GUI sandbox. This finally makes Java GUI testing reliable and predictable.

That was a long journey, and now we are here and proudly releasing Caciocavallo 1.1! Let me take this opportunity to say thanks to a couple of companies and individuals:

  • First of all, Sun Microsystems, which sparked the original idea(s) through the OpenJDK Innovators Challenge. And the folks in Sun’s graphics team, Phil Race, Jim Graham, Dmitri Trembovetski, Andrei Dmitriev and a bunch of invisible folks for following and supporting us.
  • Mario Torre, my friend and compagnon on this journey. It would not have been possible without you.
  • Of course, Clemens Eisserer for Cacio-Web and for revitalizing Cacio.
  • Andrei Dmitriev, he supported us a lot by initial testing, reporting issues, running the TCK and some then-Sun-internal test suites over it. And he presented at JavaOne 2009 about Cacio with us.
  • Aicas, who provided me and Mario with time and support on the initial OpenJDK Challenge project, and keep contributing to it, in particular:
  • Ralf Heini and Ingo Proetel, who keep submitting bug reports and fixes.
  • Glen Schrader who joined Cacio just some weeks ago to submit some important bugfixes.
  • A whole bunch of individuals who give Cacio a try, who write encouraging words in our blog comments, who lobby their development teams to use Cacio, etc etc.


Life doesn’t stop here of course. We are currently using and improving Cacio for our Thermostat at Red Hat. And we still have a long list of plans:

  • Finally get WebJDK project going. The idea is to build on top of Cacio-Web a distribution of OpenJDK that truly runs ‘in the cloud’ (i.e. on a stupid webserver farm in a boring server room). Swing applications running on WebJDK would talk directly to the client’s browser, would have (limited) access to the client filesystem and printer, will have their session managed properly, it will be scalable and easy to just throw more servers at it should resources become a problem, etc etc. I still have that filesystem support lying around on my harddisk, uncommitted.
  • Another working prototype that is uncommitted is the DirectFB port, to run Java on embedded systems, using DirectFB as graphics layer.
  • Finish a bunch of unfinished backends, in particular SDL.
  • Package Cacio for Fedora 17.
  • Plus all sorts of interesting things that we don’t know about yet, but which will surely happen.

In case you are interested in the code (*cough*), you can find source tarballs here. Or in the Cacio Mercurial repository. Or in Maven central (should appear soonish):


Please notice that Cacio only works on OpenJDK7 and most likely Oracle JDK 7  (no JDK6, no OpenJDK6, OpenJDK8 will be supported once it’s out, no other JVM runtimes like Classpath based ones are supported).