What are closures and what do they mean to Java?

I will try and show an example of what closures can be used for and how this functionality looks like if implemented in the current version of Java. I will be using the Scala programming language to demonstrate a closure. Scala is a brand new language that is running on the JVM. I am by no measure a Scala expert, actually prior to writing this post I've only spent a few hours looking at the language. Therefore if you are a Scala guru, please be gentle if commenting about the code.

Before showing you the code, let's first define what a closure is. According to Martin Fowler: A closure is a block of code that can be passed as an argument to a function call. It's not a new idea, it has been around since Scheme in the 60's. It was usually associated with functional programming and not object oriented programming, but it now exists in many OO languages like Ruby and C# (2.0). So what is that you can do with them that you cannot do in Java now?

Let us take an example of what a closure could be used for. File manipulation is a common function in any language and in many languages it requires resource handling of some sort. Doing file operations can usually be abstracted to: Opening the file, so your stuff, close the file. If you forget to close the file, this might lead to your process running out of file pointers. So let's try and abstract resource management a bit and let's write a method on a file that will let you perform an operation on each line of a file without having to worry about opening and closing the file. The example below is as I said in Scala. One of the very nice features is that you can reuse all existing Java classes, so I'll extend the File class and add a forEachLine method to it. This method allows you to pass a block of code that will be executed on each line of the file. So here is the new class:

package ScalaApplication2

import java.io.File
import java.util.Scanner

class ScalaFile(filename: String) extends File(filename: String) {

       def forEachLine(parseLine: (String) => Unit) {

               val scanner = new Scanner(this)
               try {
                       while ( scanner.hasNextLine() ) {
                               parseLine(scanner.nextLine())
                       }
               } finally {
                       scanner.close()
               }
       }

       def compareTo(other: Any): Int = {
               0
       }

}

So what is going on here? We've extended the File class and added a new method called forEachLine. It takes on parameter named parseLine and it is defined as a function type which takes one parameter of type String and returns nothing (Unit seems to be the synonym of void). As you can see, it is very easy to define a function as a parameter to a method in Scala and it is equally easy to use it inside the while loop. So now that we've implemented this new method let us look at how it can be used.

package ScalaApplication2

object ScalaMain {

       def main(args: Array[String]) = {
               val file = new ScalaFile("C:\\testFile.txt")
               var charCount = 0
               file.forEachLine((line: String) => {
                       println(line)
                       charCount += line.length()
               })
               println("Number of characters in File: " + charCount)
       }

}

So here we use the forEachLine method to print each line and count the number of characters in the file. To do this we create an anonymous function and as can be seen it is fairly straight forward. Note that the variable charCount is defined outside the scope of the anonymous function and yet can seamlessly be used inside the code block of the anonymous function. Keep that in mind for later.

Our goal of hiding resource management is reached since opening and closing the stream in encapsulated inside the forEachLine method of the ScalaFile class. Now let us look at how we can do this in Java. To get closure like behavior in Java, we need to use interfaces and anonymous classes. Below is the implementation of the new File class that we will us.

package javaapplication1;

import java.io.File;
import java.io.FileNotFoundException;
import java.util.Scanner;
import java.util.logging.Level;
import java.util.logging.Logger;

public class JavaFile extends File {

       public JavaFile(String filename) {
               super(filename);
       }

       public void forEachLine(JavaFileCallback callback) {

               Scanner scanner = null;
               try {
                       scanner = new Scanner(this);
                       while(scanner.hasNextLine()) {
                               callback.parseLine(scanner.nextLine());
                       }
               } catch (FileNotFoundException ex) {
                       Logger.getLogger(JavaFile.class.getName()).log(Level.SEVERE, null, ex);
               } finally {
                       if(scanner != null) {
                               scanner.close();
                       }
               }

       }

       public interface JavaFileCallback {

               void parseLine(String line);

       }

}

Since we cannot pass functions or methods (at least not in a type safe way) as a parameter to our method we have to use an interface with a callback method. Still our goal is accomplished, the stream is opened and closed inside our forEachLine method. Now let's look at what the caller has to do.

package javaapplication1;

import javaapplication1.JavaFile.JavaFileCallback;

public class JavaMain {

       public static void main(String[] args) {

               JavaFile javaFile = new JavaFile("C:\\testFile.txt");
               final int[] charCount = {0};
               javaFile.forEachLine(new JavaFileCallback() {
                       public void parseLine(String line) {
                               System.out.println(line);
                               charCount[0] += line.length();
                       }
               });
               System.out.println("Number of characters in File: " + charCount[0]);
       }

}

In Java, instead of having an anonymous function, we have an anonymous class that we pass to our forEachLine method. Now we all know that variables from the parent class cannot be accessed inside the anonymous class unless they are declared final. So how do we pass on our charCount variable? Well, we have to use a final object reference which variables we can mutate. In this case, we simply use an array. This adds some overhead but it is the only way to do it.

I've just demonstrated that we can replicate the exact behavior of closures with interfaces and anonymous classes. I will even go as far as saying that anything a closure can do, you can implement using the current version of Java (I will stand by this until proven wrong :-). However, that is not so much the point. This is a very simple example and there are more complex uses of closures which require even more complex code in Java. Therefore, the point is that you can do some fairly complex things with little and simple code in a language that has closures built in. In Java, you can do it but let us be honest it does not look pretty. Yet we do it everyday. Think of how many times you've had to create a runnable or callable to simply pass it on to an execution service. It would be much nicer to simply pass blocks of code around instead of actual classes and interfaces.

This is not intended to add anything new to the debate about closures in Java, just to give you an idea of what they are through a simple example. If you're interested in knowing more about closures and the many problems that need to be resolved if we want them in Java, you should check out Neal Gafter's blog. He is one of the driving forces behind the current proposal for Java and has many more examples and in depth discussions about the pros and cons (let's face it mostly pros, but it's still good reading).

Making your Java Class thread safe.

Thread safety is a very hot topic for Java programmers right now. At the JavaOne 2007, I noticed a fairly large number of technical sessions related to dealing with multithreaded code. It seems to be mostly due to the evolution of the hardware rather than a shift in paradigm in the software world. While most servers have been multiprocessor systems for a long time, most desktop computers are also starting to offer options for concurrent execution of programs, be it using multiple CPUs or a multiple core CPU. So while developers working mostly on the server side of things have been focused on building multithreaded systems, desktop developers are now also forced to take multithreaded designs into consideration. Defining the threading model for your application is probably the most important step you can take into making your code thread safe. The actual coding actually only comes second in my opinion, you need to have your threading model down beforehand so you can actually get your code right. The reason for that is that there are a lot of different ways to make your class thread safe, and you can only pick the right one if you know the thread access pattern to your class.

So what does it mean to have a thread safe class? A thread safe class is a class that guarantees the internal state of the class as well as returned values from methods are correct while invoked concurrently from multiple threads. There is an important distinction to make, just because a class is thread safe, does not mean that you cannot introduce any concurrency problems using it. The most common example of this can be found in the collections framework, consider the following code:

import java.util.Collections;
import java.util.HashSet;
import java.util.Set;

public class ThreadUnsafeBookStore {

    private final Set<Book> availableBooks = 
            Collections.synchronizedSet(new HashSet<Book>());
    
    public boolean buyBook(Book book) {
        if(availableBooks.contains(book)) {
            // Order book ...
            if(--numberRemainingCopies == 0) {
                availableBooks.remove(book);
            }
            return true;
        } else {
            return false;
        }
    }
}

We are using a synchronised Set to keep track of the available books at this particular bookstore. Basically any number of threads can access the availableBooks Set concurrently and the set will maintain a consistent internal state, however that does not mean that the state it represents in the book store will remain consistent. Imagine two customers trying to buy the same book at the same time, yet the book store only has one copy left. Two threads enter the buyBook() method and one possibility for the order of execution is as follows (thread one is green, the other is red):

availableBooks.contains(book)
Order book ...
availableBooks.contains(book)
Order book ...
if(--numberRemainingCopies == 0)
availableBooks.remove(book)
return true;
if(--numberRemainingCopies == 0)
return true;

In this example, both customers managed to order the book, but there will be one unhappy customer because in the physical world the bookstore only has one copy. There is a couple of ways to fix this, one is to declare the buyBook() method synchronized in which case only one thread at a time would be able to execute this method. However, that is somewhat misleading synchronization, synchronizing the method means you are taking the Monitor on the BookStore instance, but that is not the resource you are actually worried about. The resource you need to restrict concurrent access to is the availableBooks Set. The following code is more explicit about that.

import java.util.HashSet;
import java.util.Set;

public class ThreadSafeBookStore {

  private final Set<Book> availableBooks = new HashSet<Book>();

  public boolean buyBook(Book book) {
    synchronized (availableBooks) {
      if (availableBooks.contains(book)) {
        // Order book ...
        if (--numberRemainingCopies == 0) {
          availableBooks.remove(book);
        }
        return true;
      } else {
        return false;
      }
    }
  }
}

This code clearly indicates that the synchronized block of code is accessing the availableBooks resource and we need to protect this resource from concurrent access. A side effect of this is that you do not need to use a synchronized set anymore (if you put all accesses to it inside a synchronized block as shown in buyBook()). This is also more flexible when managing threaded access to the BookStore class. Imagine that you have several resources that you need to protect in your class, then synchronizing on the BookStore instance is inefficient, because you might only access one of the resources in one method, while another method uses another resource. Synchronizing on the BookStore instance, only one thread at a time can work, but synchronizing on individual resources several threads can work on the bookstore concurrently as long as they don’t access the same resources inside the bookstore.

The synchronized keyword is a fairly straightforward, but powerful, tool to make your classes thread safe. However, it is not the only option you have available; let us look at another example of an unsafe class, this time dealing with visibility.

public class ThreadUnsafeBean {
    
    private int x;
    
    public int getX() {
        return x;
    }

    public void setX(int x) {
        this.x = x;
    }
}

Right now you might be wondering what could possibly go wrong with this code, certainly it doesn’t get more basic than this. The problem resides in the Java memory model, which allows the JVM to optimize a number of things, especially when it comes to memory accesses. Reading something from memory is expensive in a program, especially when you have all these nice registers and caches around in your CPU. Each thread is allowed to have its own cache of sorts, so for the following sequence of calls you could run into a problem.

setX(0)
setX(1)
getX()
getX()

Thread one (in green) could reasonably expect the getX() method to return 1, since thread 2 (in red) set the value to 1 previously. However, because the JVM is allowed to optimize access to field values, it can retrieve the value of x from the threads own cache which at this point contains the value 0. This code is so simple and appears in so many programs, how come we don’t get that error more often? Well, mainly because most JVM implementation will only optimize this for systems with many CPUs or hardware that has a memory management that supports this kind of optimizations. For example the x86 architecture has a memory management model that is quite conservative, so you’re unlikely to see this problem on that platform. However, that might change and if you move your application to a platform that does more memory optimizations, this problem might show up a lot more often. One of the ideas behind Java is write-once run anywhere, and that is actually possible since the Java memory model is the same independent of the underlying hardware platform or OS. So how do we fix this code?

One option is to declare the getX and setX methods as synchronized, because in addition to making sure that only one thread at a time can execute the method, the thread will synchronize its cache with the values stored in memory. This will work and you are assured that you will always get the right value of x. This is however not the best solution because this could cause quite a lot of thread contention and is overkill because you don’t want to restrict access to the method to one thread at a time, you just want the value x to be visible to all threads at all time. Therefore, consider the second option shown below.

public class ThreadSafeBean {
    
    private volatile int x;
    
    public int getX() {
        return x;
    }

    public void setX(int x) {
        this.x = x;
    }
}

The volatile keyword ensures that we will always get the in memory value of the integer x. This is lot cheaper than synchronizing the entire bean instance which might contain other values than just x. This is a good solution, a better but more constraining solution, is to make the bean immutable. This can only be done if you only intend to set the value of x once.

public class ThreadSafeBean {
    
    private final int x;

    public ThreadSafeBean(int x) {
        this.x = x;
    }
    
    public int getX() {
        return x;
    }

}

The final keyword means that the value of this field once set cannot be changed. This also has repercussions for thread safety, because Java then also guarantees that the value will be seen by all threads without the need for any locking.

These few advices should help you implement thread safe classes. We looked both at the problems of state consistency and state visibility, and the language tools at our disposition to prevent them. Generally synchronize as little as possible, synchronization is not a big performance hitter anymore, but can still introduce problems with thread contention if you have many threads running. So instead try to use volatile when possible, and ideally make classes immutable. However, too much synchronization is still better than too little. Another important aspect is to document thread safety on your classes in the Javadoc, that goes for thread safe and unsafe classes. You documenting your class clearly signals to other developers what they can and can’t do with it, and as a lucky side effect might also make them ponder thread safety issues in their own code. If you are further interested in threading issues and solutions in Java, I recommend that you read Java Concurrency in Practice by Brian Goetz. It is an excellent book, well written and complete, about multithreading in Java.

Developing a Swing application: Why all the cursing?

If you’ve been around for enough time you have certainly heard your share of complaints about Swing, which usually from it is too complex, the UI is ugly, to it is too slow. Why all the cursing against Swing? Most certainly my few years of experience have taught me to be careful when coding with Swing components, and even more so during the design phase of my application. But is the Swing framework really to blame for all the failures? If you actually follow the rules and best practices as documented by its designers, will you end up with a fast, usable and appealing client? I believe you will and this has been proven by quite a few clients out there, some of the best examples can be found at the Swing sightings page. In this post, I will try and go through the main challenges, and give a few pointers to solutions, when writing Swing applications.

On modern hardware, you need to be able to run things in parallel in order to have access to the computational resources of your environment. You usually have multiple CPUs or Cores, and you want to be able to use all the available cycles available to you. In Java, this is mostly done using threads, and lots of them (Take a thread dump of any of your Java applications and you will see that even though you didn't create any, the JVM already has quite a few of its own). Creating a single threaded application is still possible but it should be restrained to simple applications (You don't want to bother with multi threading for implementing Tic-Tac-Toe). Java was one of the first languages to fully embrace threading as part of its specification. You can create multi threaded code that is both correct and portable, however, as all things code, it is only correct if you code it right, which can prove to be a challenge (Regardless of the Java language, code executed by multiple threads is hard to get right). So how does Swing propose to help with this? Well, by making all access to Swing components single threaded... Wait a minute! You just said that to create an efficient application you need to run things in parallel, with like multiple threads and stuff??? How does this help? Well, in fact it doesn’t and that is why you need to be extra careful when writing applications using the Swing framework.

Let’s just pause a moment and see why the single threaded model. Ideally, you would like to be able to just spawn of threads each time there is a new action taking place in your client. That should make use of all the available CPU time we can get, right? First, spawning off threads is not free, so you don't want to do it each time the user hits the keyboard or moves the mouse. Second, you're likely to chase bugs until the end of time itself and then for a little while longer. Each time a thread accesses a shared resource you need to synchronize access to it to make sure that the resource remains consistent through the multiple accesses. Now that you have synchronized the access to all shared resources (or more likely all the ones you know about) you've opened the door for deadlocks and still haven't fixed race conditions occurring because some threads need to synchronize access across several resources. So basically the wild wild west of threading is likely to see a lot of unlawful behaviour and not be that efficient at all because of all the time spent synchronizing. AWT, the predecessor to Swing and its foundation actually tried to deliver a framework allowing concurrent access through multiple threads. Let's just say that Sun's bug database regarding AWT is unlikely to be empty of threading issues anytime soon. Swing tried to fix that by introducing a simple, yet so hard to enforce, rule that all Swing components must be accessed by a single thread, namely the Event Dispatch Thread (EDT).

So how is this done? Well quite simply, each time you access some Swing resource (both reading or changing), you need to package it inside a new Runnable that you pass on to the EventQueue, just like this:

Runnable swingRunnable = new Runnable() {
  public void run() {
    // Doing some Swing stuff...
  }
}
EventQueue.invokeLater(swingRunnable);

This plain sucks because, first these few lines of code will potentially be repeated over and over again in your code, this, however, in the minor annoyances category. Second, you only have one thread to execute all your code. This is a bit more critical; while the EDT is busy, clicking buttons and hitting the keyboard has no apparent effect, because your application cannot process these events until the current job on the EDT is done. This is a concern of perceived performance, most people don’t really mind looking at a progress bar (Actually, it can be quite fascinating), but looking at a frozen application will significantly increase their blood pressure. You don’t get things done faster with a progress bar, but the elapsed time somehow gets more acceptable. Thirdly, I sometimes forget to turn off the ironer, and while I might get away with it for my entire life, there's a chance that I will set my house ablaze some day. It is the same with Swing code, if you forget to put it on the EventQueue, it’s probably going to be okay, most of the time... However, some day you might receive a call from your customer at the hospital, asking why the application displayed the wrong amount of medication for that now deceased patient. Then, you’d wish your house went ablaze so you wouldn’t have had time to write that fatal line of code.

The first problem can be largely remedied be getting your design work right and structuring your code so that the Swing code is isolated from the rest of the code. If you end up having several invokeLater() calls inside a single method, it probably means you need to refactor your code. This might not always be possible with legacy code, in which case you might just have to live with it, you probably will have to live with worse things in your life as a code monkey.

The second problem is the single greatest cause of poorly performing Swing applications out there, some people have actually given up because of this, cursing the Swing framework for its slowness. So how do you fix this? Well several solutions exists more of less refined, but they all come from the same basic principle. You need to keep the amount of code executed on the EDT to a minimum and spawn as much processing as possible to other threads. Ideally, the code executed on the EDT only updates the state of the Swing components to reflect the results of the processing, not the processing in itself. If you do this, then your application would have a good perceived performance in most cases, and if you had some status reporting, like an hourglass or a progress bar, then you are almost certainly home safe. To help doing that several libraries and utility classes exist, the most famous is probably the SwingWorker, which is now part of the standard JDK since Java 1.6. This class allows you to easily split your code up into background processing code and Swing code. Other nice helper libraries include SPIN and the earlier Foxtrot. These two libraries decouple the actual data model from you Swing components. Looking forward you should pay attention to JSR 296, Swing Application Framework, which promises to include new concepts and utilities to ease threading concerns in Swing. So all is actually good in the fantastic world of Swing, well almost… The Swing framework actually has a few problems on its own, related to the infamous grey rectangle.

The grey rectangle problem is when some part of your application does not get repainted immediately and the region just shows up as a grey area, usually rectangular. This is actually caused by a deficiency in the design of Swing. Normally, the OS passes on events to applications for them to process the event and repaint part of their display if necessary. During that time, the OS is smart enough to realize that while processing the event, the application is not able to repaint itself should a new event force that, so the OS actually caches the current display of the application. Meaning that, even if you move another window on top of a busy application and move it away, the OS can use the cache to paint the busy application after the other window is moved away. The OS knows to use the cache because the application hasn’t returned from the last event that was passed to it. Swing on the other hand decouples the event processing from the OS, by placing the event on the EventQueue and returning control to the OS immediately. The OS has now no way to know that the application is still busy handling that event passed to it a while, and therefore does not use its cache to display the window. This problem is pretty much insolvable unless you change the fundamental design of Swing. A few things have been done to alleviate it over time, like in Java 1.6 with the introduction of double buffering on all components. All this means is that Swing repaints faster, meaning the grey rectangle is less likely to be noticeable. However, all these optimizations are not pointless, because if you actually keep the EDT mostly free, your application will plenty of time to repaint itself on a modern desktop.

The third problem is probably the most serious of all, because it is sneaky in its nature. It will remain hidden most of the time; you can successfully go through internal test, beta release, a few years of field test, until one day, it strikes in a place where you really did not want it to happen. Good design and implementation practices can help you avoid it to a certain extend, but even the best developers make mistakes (In fact, a good developer is often differentiated from a bad one, by the simple fact that he admits to making mistakes, and does something to catch them.) Static code analysis is unlikely to be able to detect this problem; this is in essence a runtime problem. Is my code running in the right thread? A few simple tricks, can allow you to detect violations to the rule. You can write a custom RepaintManager that will override the addDirtyRegion(), markCompletelyDirty() methods to check that these methods are being executed on the EDT. This can be simply done like this:

public class CustomRepaintManager extends RepaintManager {
 public void addDirtyRegion() {
   if(!EventQueue.isDispatchThread()) {
     throw new RuntimeException(“Running on the wrong thread!”);
   }
   super.addDirtyRegion();
 }
}

This will detect all accesses that would cause a repaint on the wrong thread. This, however, does not catch calls to Swing components that to not cause a repaint, which might lead to equally embarrassing bugs. An elegant solution to that is the use of aspects to do the detection. I will go more in depth with that solution and aspects in my next posting.

I hope this way too long posting has helped to give you a better understanding of the challenges involved in writing Swing applications and some pointers to a few solutions. In my opinion, if the development team keeps an eye on the few problems outlined here, developing Swing applications can give great results and be very cost efficient. Especially, if developing for several platforms, one of the main design goals of Swing is after all portability, which it has been largely successful.