Java: Cleaning up after yourself

Most sensible Java programmers know that garbage collection is no substitute for careful de-allocation of resources. In Java that a class typically allows you to do this on a per object basis with the close method. On .net, this the equivalent is the dispose method.

Clean up is also not an easy task because a method could return from multiple places and exceptions can be thrown from anywhere.

Take for instance the following code that writes a line to a file:

final PrintWriter pw = new PrintWriter("hello.txt");
pw.println("Hello world");
pw.close();

It’s quite straight forward: Open a file, write to the file, close the file. Cleanup is taken care of right?

Not really. Any of the three lines could potentially throw an exception. The first line in particular throws the checked FileNotFoundException.

Java provides the try, catch and finally keywords to deal with problem.

So how about this?

try {
  final PrintWriter pw = new PrintWriter("hello.txt");
  pw.println("Hello world");
} catch (final FileNotFoundException e) {
  // log error
} finally {
  pw.close();
}

Unfortunately it doesn’t compile because pw is out of scope in the finally clause so pw.close() is a compile error.

So we try again, this time having two try blocks: One for the close operation and another for catching the exception:

try {
  final PrintWriter pw = new PrintWriter("hello.txt");
  try {
    pw.println("Hello world");
  } finally {
    pw.close();
  }
} catch (final FileNotFoundException e) {
  // log exception
  throw e;
}

For each new resource we want to open and then access together, we need a new try and finally block and potentially a new try and catch block:

try {
  final PrintWriter pw1 = new PrintWriter("hello.txt");
  try {
    final PrintWriter pw2 = new PrintWriter("hello.txt");
    try {
      pw1.println("Hello world");
      pw2.println("Hello world");
    } finally {
      pw2.close();
    }
  } finally {
    pw1.close();
  }
} catch (final FileNotFoundException e) {
  // log exception
  throw e;
}

If a large number of resources need to be opend simultaneously, it can be help to create a class to help close all resources.

public class Disposer {
  ...

  public <T extends Closeable> T disposes(
      final T closeable);

  public void dispose();
}

The disposes method registers the closeable object with the disposer object. The dispose method will call close on all registered objects in reverse order. The implementation is left to the reader as an exercise.

This class will allow us to use only one try block for everything:

final Disposer disposer = new Disposer();

try {
  final PrintWriter pw1 = disposer.disposes(new PrintWriter("hello.txt"));
  final PrintWriter pw2 = disposer.disposes(new PrintWriter("hello.txt"));
  pw1.println("Hello world");
  pw2.println("Hello world");
} catch (final FileNotFoundException e) {
  // log exception
  throw e;
} finally {
  disposer.dispose();
}

The code is much shorter and more readable.

Posted in Uncategorized | Leave a comment

Java NIO: Must remember to avoid using SelectionKey.attachment

Must remember than SelectionKey.attachment is evil and should never be used to store anything that has a handle on a buffer.

Posted in Uncategorized | Leave a comment

Scala: More differences from Java

Method declarations use the def keyword and follow’s Scalas syntax rules of putting the type after the symbol for argument variables. In our send method below, the statements within look a lot like Java code with some minor differences:

  def send(socket: SocketChannel, data: Array[Byte]) {
    this.pendingChanges.synchronized {
      // Indicate we want the interest ops set changed
      this.pendingChanges.add(new ChangeRequest(socket, ChangeRequest.CHANGEOPS, SelectionKey.OP_WRITE))

      // And queue the data we want written
      this.pendingData.synchronized {
        var queue: java.util.List[ByteBuffer] = this.pendingData.get(socket)
        if (queue == null) {
          queue = new java.util.ArrayList[ByteBuffer]()
          this.pendingData.put(socket, queue)
        }
        
        queue.add(ByteBuffer.wrap(data))
      }
    }

    // Finally, wake up our selecting thread so it can make the required changes
    this.selector.wakeup()
  }

On line 2, synchronized is a method, not a keyword as it was in Java. The block that follows is a closure. That means it is an anonymous function object that has access to variables in the scope it was declared. In this case it has access to the socket and data argument variables. This closure is passed into the synchronized method and the resulting behaviour is identical to the Java synchronized block.

The following run method shows more Scala language constructs:

  def run() {
    while (true) {
      try {
        // Process any pending changes
        this.pendingChanges.synchronized {
          val changes = this.pendingChanges.iterator()
          
          while (changes.hasNext()) {
            val change = changes.next()
            
            change.`type` match {
            case ChangeRequest.CHANGEOPS =>
              val key = change.socket.keyFor(this.selector)
              key.interestOps(change.ops)
            }
          }
          
          this.pendingChanges.clear()
        }

        // Wait for an event one of the registered channels
        this.selector.select()

        // Iterate over the set of keys for which events are available
        val selectedKeys = this.selector.selectedKeys().iterator()
        while (selectedKeys.hasNext()) {
          val key: SelectionKey = selectedKeys.next()
          selectedKeys.remove()

          if (key.isValid()) {
            // Check what event is available and deal with it
            if (key.isAcceptable()) {
              this.accept(key)
            } else if (key.isReadable()) {
              this.read(key)
            } else if (key.isWritable()) {
              this.write(key)
            }
          }
        }
      } catch { case e: Exception =>
        e.printStackTrace()
      }
    }
  }

The familiar while loop is used on line 2, although you will find that Scala doesn’t support Java’s continue or provide an equivalent. This is why the key.isValid() test is inverted to avoid needing to use a continue construct.

Line 11 has a statement that would be quite unfamiliar to Java programmers. It’s analog in Java is the switch statement, but is is way more powerful. The Java switch statement can only be used in non reference types and enumerations. The Scala match statement can be used on any object and can even be used to deconstruct complicated objects to get at their components. The code on line 11, however, behaves just like a switch statement does: The block inside the match block but under the case statement executes only if change.`type` and ChangeRequest.CHANGEOPS have the same value.

There is also a try block that at first glance looks very much like the Java equivalent apart from the syntax differences. The semantics are different however and much more powerful. As written it binds the caught exception object to e if the type of the exception object is Exception and then executes the code following =>.

Here is another method that demonstrates some more Scala features:

  private def write(key: SelectionKey) = {
    val socketChannel = key.channel().asInstanceOf[SocketChannel]

    this.pendingData.synchronized {
      val queue = this.pendingData.get(socketChannel)

      // Write until there's not more data ...
      val breaks = new Breaks
      breaks.breakable {
        while (!queue.isEmpty()) {
          val buf = queue.get(0)
          socketChannel.write(buf)
          if (buf.remaining() > 0) {
            // ... or the socket's buffer fills up
            breaks.break
          }
          queue.remove(0)
        }
      }

      if (queue.isEmpty()) {
        // We wrote away all data, so we're no longer interested
        // in writing on this socket. Switch back to waiting for
        // data.
        key.interestOps(SelectionKey.OP_READ)
      }
    }
  }

Line 2 shows how casts are performed in Scala. There is no special cast syntax as there is in Java or C. Instead, use the asInstanceOf method supplying the desired type as the type argument to this method.

While support for continue doesn’t exist, there is support for a break construct in the Scala library that can be used to break from loops. It is however a little more involved. You need to create an object of the type Breaks, and then use the breakable method of the object to delimit the area you would want to break from. When the break method is invoked, the program control will continue from the point after where the break method is called. By delimiting the code with the breakable method, it is possible to precisely control where the break puts the program control.

Finally as there is no support for static methods, the main method is declared just the way you would expect: a normal method in a singleton object:

object NioServer {
  def main(args: Array[String]) = {
    try {
      val worker = new EchoWorker()
      new Thread(worker).start()
      new Thread(new NioServer(null, 9876, worker)).start()
    } catch { case e: IOException =>
      e.printStackTrace()
    }
  }
}
Posted in Uncategorized | Leave a comment

Scala: Declaring classes

Scala classes are public by default. It Java, to define a class with a field, you need to define the field an argument in the constructor for that field and an assignment from the argument to the field to initialise it. Scala allows you to declare it once and have it all done for you. For instance, the Java class:

public class ChangeRequest {
  public SocketChannel socket;
  public int type;
  public int ops;
  
  public ChangeRequest(SocketChannel socket, int type, int ops) {
    this.socket = socket;
    this.type = type;
    this.ops = ops;
  }
}

condenses to the Scala code:

class ChangeRequest(
    val socket: SocketChannel,
    val `type`: Int,
    val ops: Int) {
}

The backticks here are used to avoid Scala interpreting type as a keyword. The braces are optional if empty so the following would be fine as well.

class ChangeRequest(val socket: SocketChannel, val `type`: Int, val ops: Int)

We all want to declare something like this in our Scala ChangeRequest class:

  public static final int REGISTER = 1;
  public static final int CHANGEOPS = 2;

but Scala does not support static methods or fields because they don’t have OO semantics. Instead we define a singleton object of the same name as the class and add fields to that:

object ChangeRequest {
  val REGISTER = 1
  val CHANGEOPS = 2
}

There is not conflict between the class name and the object name because they are in different namespaces. Types always appear after the : or between the [] in Scala.

In Java you create a class with a class declaration, and in the class body, you put method and constructor declarations and in the method and constructor bodies you put your statements.

Scala is very similar except that your class body is also a constructor. Being a constructor means that statements can be placed in the class body and interleaved with field declarations. Scala will execute the class body as if it were a constructor from top to bottom. This is a clever way to reduce the amount of code. In Java it is typical to have to declare fields and initialise them in separate places, but in Scala it is much more readable as it is all in one place.

class NioServer(
    private val hostAddress: InetAddress,
    private val port: Int,
    private val worker: EchoWorker) extends Runnable {
  // The channel on which we'll accept connections
  // Create a new selector
  private val selector = SelectorProvider.provider().openSelector()

  // Create a new non-blocking server socket channel
  val serverChannel = ServerSocketChannel.open()
  serverChannel.configureBlocking(false)

  // Bind the server socket to the specified address and port
  val isa = new InetSocketAddress(this.hostAddress, this.port)
  serverChannel.socket().bind(isa)

  // Register the server socket channel, indicating an interest in 
  // accepting new connections
  serverChannel.register(selector, SelectionKey.OP_ACCEPT)

  // The buffer into which we'll read data when it's available
  private val readBuffer: ByteBuffer = ByteBuffer.allocate(8192)

  // A list of PendingChange instances
  private val pendingChanges: java.util.List[ChangeRequest] = new java.util.LinkedList[ChangeRequest]()

  // Maps a SocketChannel to a list of ByteBuffer instances
  private val pendingData: java.util.Map[SocketChannel, java.util.List[ByteBuffer]] =
    new java.util.HashMap[SocketChannel, java.util.List[ByteBuffer]]()

  // ... method declarations ...
}

In the above code hostAddress, port and worker are arguments to the NioServer constructor but also double as private immutable field declarations. In the class body selector, readBuffer, pendingChanges and pendingData are private fields while serverChannel and isa are public fields. Some statements are freely interleaved between these field declarations and all statements and field initialisations in the order that it would as if it were just normal code.

Additional constructors could be added, however all these if added would essentially delegate to the main constructor we have just declared after some performing some processing.

Posted in Uncategorized | Leave a comment

Scala: Rewriting from Java

I’ve taken the ROX NIO tutorial code, fixed it up a bit, translated it to Scala and uploaded both the Scala and Java to https://offsync.googlecode.com/svn/tags/rox-nio-tutorial-source

I’ll be looking at some of the differences between the Scala and Java code.

Posted in Uncategorized | Leave a comment

Very useful Java NIO resource

I highly recommend the ROX Java NIO Tutorial for learning about Java NIO. Java NIO made no sense to me whatsoever until I read this page.

Posted in Uncategorized | Leave a comment

Scala: Declaring variables and methods

The first thing that hit me in my first encounter in Scala is the different syntax for the declaration of variables.

In Scala it is defined in one of two ways:

val immutableValue: Int = 1
var mutableValue: Int = 2

The first line defines an immutable value (i.e. constant value) that doesn’t ever change and the second line defines a mutable value.

This differs from the Java equivalent:

final int immutableValue = 1;
int immutableValue = 2;

So far, the difference is only syntactic and individuals might prefer one syntax over the other as a matter of style. Nevertheless the Scala syntax does have a lot of practical advantages.

Firstly, Scala allows for the type of the variable to be omitted whenever the compiler is able to deduce it. That means I can write the following shorter alternative instead:

val immutableValue = 1
var mutableValue = 2

The shorter Scala version is also a lot easier to read.

Secondly, the syntax makes more complicated declarations more consistent. For instance why does Java sometimes put the generic types before the symbol being declared and sometimes after?

In the following Java code, the type argument T is declared after the interface name MyInterface whereas the type argument <U> appears before the method name foo.

public interface MyInterface<T> {
  public <U> U foo(U arg);
}

In Scala, the generic type delcarations always occur immediately after the symbol to which it appears:

trait MyTrait[T] {
  def foo[U](arg: U): U
}

The reason for the Java inconsistency is that it is difficult to write a parser for that will work for the syntax a Java programmer might prefer:

public interface MyInterface<T> {
  public U foo<U>(U arg);
}

This is because the foo method returns U, but the parser cannot know that U is a generic type – probably assuming it is a normal class name until it has found <U>, by then it has to undo all its assumptions.

It is telling that even C++ is adopting a syntax where the type comes after the symbol because designing a decent language with the C-like syntax for declarations is just too hard.

More consistent rules and fewer exceptions means a simpler language. It’s why I think Scala is how Java should have been designed.

Thirdly functions a first class value meaning I can treat them as normal objects and declare them easily:

lazy val fib: Int => Int = { n =>
  if (n < 2) {
    return 1
  } else {
    return fib(n - 1) + fib(n - 2)
  }
}

This defines the variable fib. Its type is a function that takes an argument of type Int and returns a value of type Int. The name of the argument is n. The variable declaration includes the lazy keyword because the function being defined is recursive. This delays the creation of the function object until the first use of the fib variable allowing the fib variable to occur first so that it is available for the function object to be created. There is no Java equivalent.

To call this function object, simply use the function call syntax:

println(fib(10))

Imagine how horrible it is to define something like this in Java. First I have to define the type of my function object because Java has no built-in concept of a function type:

public interface IntToInt {
  public int call(
      final int argument);
}

Then I have to define the function object via a anonymous class declaration:

final IntToInt[] fib = new IntToInt[1];
fib[0] = new IntToInt() {
  public int call(
      final int n) {
    if (n < 2) {
      return 1;
    } else {
      return fib[0].call(n - 1) + fib[0].call(n - 2);
    }
  }
};

And finally the function call:

System.out.println(fib[0].call(10));

The code is a disaster. It is twice as long and isn’t even generic. I might call this type IntToInt and the method call while someone else might call it FInt2Int and invoke respectively and even though these types represent the exact same concept, they aren’t compatible.

Furthermore, because the lack of a lazy keyword, in order to define a recursive function object, I need to declare a single element array. This is because anonymous classes can only access variables declared its scope if it is final. Yet when to the fib is defined to be a final variable of type IntToInt, the function object can’t reference it either because the attempt to create the function object occurs before the fib variable is defined.

To rub salt in the wound, the same thing can be written in one line of Scala:

lazy val fib: Int => Int = n => if (n < 2) 1 else fib(n - 1) + fib(n - 2)
Posted in scala, software development | Leave a comment