Once upon a time, I was working on the assignment for the SCJD certification. The project was a classic client-server application, with an RMI server, and a Swing-based GUI, which you could use to book hotel rooms or some such. One of the project requirements was to provide record locking, such that only one instance of the client could edit the hotel room entry at once. Fairly standard stuff. So, when the user clicks Edit Room in the client GUI, the client makes an RMI call to acquireLock, and when that method returns, the client can then call update, and so on. But if another client already has the lock, then the acquireLock method will block until the lock becomes available. In that case, the app shows a pleasant dialog like this:

Obviously you, as the user, would like to be able to click Cancel. And obviously you, as the developer, would like the RMI thread that’s stuck in the remote acquireLock method to return promptly. But you, as the developer, would be sorely disappointed, because the RMI thread will continue to block. Indefinitely! And from this outrage, thus was born the Interruptible RMI library.

My years toiling away on web services seem to be paying off: I’ve been invited to be a member of the JCP Expert Group for JSR-261 (Web Services Addressing). A primer: JCP is the Java Community Process: it’s the mechanism for developing standard technical specifications for Java technology. Basically, whatever is decided upon in a JSR goes into the next version of Java. JSR is a Java Specification Request: the formal documents that describe proposed specifications and technologies for adding to the Java platform.

For the best part of the last year I’ve been an active contributor to some of the Apache Commons projects (specifically Collections and Lang). I’m now an official committer at the ASF, with write access to the VCS and what not. And a shiny @apache.org email address.