Marc Seeger kindly informed me today, that the Java Posse was doing a section (mp3) in their latest episode on my recent blog post Java Swing is not thread-safe. This would have totally slipped past me if it hadn’t been for Marc, so thanks a lot Marc! Also, I would like to thank the Java Posse for linking to my post, although I wish it had been a post that I had put more thought and effort into.

I’m currently writing my Bachelor’s Thesis on concurrency and how different programming languages address the issue. While doing the research for that, I also looked at Java and some of the more popular Java libraries. So I’m approaching this issue from a concurrency point of view and not so much from a Java point of view. Also, I’m by no means a Java, let alone a Swing expert. I have written some Java code that made it into a product, but I don’t normally use Java professionally. I wrote the “Swing isn’t thread-safe” post because I realized that there are all these Java programmers who have never had to worry about thread-safety before, and now they’re told that they have to write multi-threaded code to make use of multi-core CPUs. I believe this spells disaster, not only because Java’s concurrency model is inherently broken (pdf), but also because shared-state-concurrency in general is inherently broken. But even if you ignore this fact for a second and imagine that not only are they writing multi-threaded code, they’re also writing it against GUI toolkits that aren’t thread-safe, I think you will understand what motivated me to write that post.

I realize after listening to the Java Posse episode that my post was way too short and that I hadn’t put enough thought into it. That’s probably also why the Java Posse misquoted me on two separate issues. For one, they quote me of saying that Swing was single-threaded. If you read my post, you’ll realize that I only ever talked about Swing not being thread-safe. Also, at one point they use the quote “shouldn’t we make the GUI faster” which again I neither said nor meant. When I said “we're in a multi-core world now and unless you want your applications to become slower in the future, you'll eventually have to go multi-threaded as well” I was of course talking about application code and not the GUI toolkits. So I guess what lead to the misunderstandings was a lack of clarity on my side and maybe a little carelessness on the Java Posse’s side. Either way, that episode of the Java Posse was very interesting and enlightening, but as far as my blog post goes, they were missing the point. I don’t blame them though because again, things might not have been as clear as they should have been.

What I wanted to discuss in my blog post wasn’t so much whether Swing should be thread-safe or not, but if we can look into our concurrent future with confidence and to be frank with you, I think we’re all doomed. All popular programming languages including Java, C# and C++ build their concurrency model around the concept of threads and locks (actually I should exclude C++ here because it doesn’t have a concurrency model yet). While nobody really knows what the ideal concurrency model is (or if there even is a single ideal concurrency model), most people in computer science agree that threads and locks is not it. I could go into great detail as to why that is, but that’s a topic for a different blog post. So let’s just say that writing non-trivial concurrent applications using threads and locks is extremely difficult and even experienced programmers get it wrong all the time. It usually boils down to either using too much (or too coarse-grained) synchronization which produces sequential bottlenecks or to using too little synchronization which results in race conditions. Both cases are undesirable, but race conditions are actually beyond being just undesirable. They’re evil. In fact, they are so evil, that they sometimes kill people. Now imagine a few years from now, everybody’s writing multi-threaded applications and not only are we using programming languages that are ill-equipped for it, we’re using libraries that aren’t thread-safe. And even worse, most of us don’t even know that the libraries aren’t thread-safe.

In the case of Java Swing, a lot of people will argue that you usually won’t have to mutate the state of your GUI objects from within multiple threads. In fact, it’s generally a bad idea to do so from a software design perspective. This argument however is flawed and I will tell you why. In C++ just like in Java there is an operator called new that allocates memory. Unlike in Java however, a second operator delete exists that you have to explicitly call to free any memory that you have previously allocated with new. If you forget to call delete, you create a memory leak. Not surprisingly, a lot of applications written in C++ leak memory. In my opinion, this isn’t because these applications were written by bad programmers but because the concept of manual memory management is inherently flawed. This really boils down to a question of mentality. C++ trusts the programmer, Java does not. Java is usually very good at taking away the sharp and pointy things. There is no pointer arithmetic, no manual memory management, none of the dangerous fun stuff. What’s very surprising though is that Java still relies on threads and locks for its concurrency model, which, speaking in terms of sharp and pointy things, is a giant syringe filled with concentrated AIDS. The same applies to Swing not being thread-safe. It isn’t so much that there aren’t good reasons for making a GUI library thread-unsafe, it’s just that it doesn’t fit the Java mentality. You can’t twiddle with pointers, but you’re welcome to have a hundred threads invoking methods on a GUI component in an unsafe manner. That just doesn’t seem right.

So should Swing be thread-safe then? I don’t know the answer to that question. What I do know however is that if multi-core is the future (and I do believe that it is), we’re going to need a better concurrency model. The Erlang concurrency model appears to be a strong contender for that position.