Reduce Java boilerplate using try-with-resources
Posted on August 11, 2016 by Scott Leberknight
Java 8 has been out for a while, and Java 7 has been out even longer. But even so, many people still unfortunately are not taking advantage of some of the new features, many of which make reading and writing Java code much more pleasant. For example, Java 7 introduced some relatively simple things like strings in switch statements, underscores in numeric literals (e.g. 1_000_000 is easier to read and see the magnitude than just 1000000), and the try-with-resources statement. Java 8 went a lot further and introduced lambda expressions, the streams API, a new date/time API based on the Joda Time library, Optional, and more.
In this blog and in a few subsequent posts, I will take a simple snippet of code from a real project, and show what the code looked like originally and what it looked like after refactoring it to be more readable and maintainable. To start, this blog will actually tackle the try-with-resources statement introduced in Java 7. Many people even in 2016 still seem not to be aware of this statement, which not only makes the code less verbose, but also eliminates an entire class of errors resulting from failure to close I/O or other resources.
Without further ado (whatever ado actually means), here is a method that was used to check port availability when starting up services.
public boolean isPortAvailable(final int port) {
ServerSocket serverSocket = null;
DatagramSocket dataSocket = null;
try {
serverSocket = new ServerSocket(port);
serverSocket.setReuseAddress(true);
dataSocket = new DatagramSocket(port);
dataSocket.setReuseAddress(true);
return true;
} catch (IOException e) {
return false;
} finally {
if (dataSocket != null) {
dataSocket.close();
}
if (serverSocket != null) {
try {
serverSocket.close();
} catch (IOException e) {
// ignored
}
}
}
}
The core logic for the above code is pretty simple: open a ServerSocket and a DatagramSocket and if both opened without throwing an exception, then the port is open. It's all the extra boilerplate code and exception handling that makes the code so lengthy and error-prone, because we need to make sure to close the sockets in the finally block, being careful to first check they are not null. For good measure, the ServerSocket#close method throws yet another IOException, which we simply ignore but are required to catch nonetheless. A lot of extra code which obscures the actual simple core of the code.
Here's the refactored version which makes use of the try-with-resources statement from Java 7.
public boolean isPortAvailable(final int port) {
try (ServerSocket serverSocket = new ServerSocket(port);
DatagramSocket dataSocket = new DatagramSocket(port)) {
serverSocket.setReuseAddress(true);
dataSocket.setReuseAddress(true);
return true;
} catch (IOException e) {
return false;
}
}
As you can hopefully see, this code has the same core logic, but much less of the boilerplate. There is not only less code (7 lines instead of 22), but the code is much more readable since only the core logic remains. We are still catching the IOException that can be thrown by the ServerSocket and DatagramSocket constructors, but we no longer need to deal with the routine closing of those socket resources. The try-with-resources statement does that task for us, automatically closing any resources opened in the declaration statement that immediately follows the try keyword.
The one catch is that the declared resources must implement the AutoCloseable interface, which itself extends Closeable. Since the Java APIs make extensive use of Closeable and AutoCloseable this means that most things you'll want to use can be handled via try-with-resources. Classes that don't implement AutoCloseable cannot be used directly in try-with-resources statments. For example, if you are unfortunate enough to still need to deal with XML, for example if you need to use the old-school XMLStreamReader then you are out of luck since it doesn't implement Closeable or AutoCloseable. I generally fix those types of things by creating a small wrapper/decorator class, e.g. CloseableXMLStreamReader, but sometimes it simply isn't worth the trouble unless you are using it in many difference places.
For more information on try-with-resources, the Java tutorials on Oracle's website has a more in-depth article here. In subsequent posts, I'll show some before/after code that makes use of Java 8 features such as the stream API and lambda expressions.
This blog was originally published on the Fortitude Technologies blog here.
