A nice feature of the Java 7 try-with-resources statement and the AutoCloseable type that was introduced to work with this statement is the fact that static code analysis tools can detect resource leaks. For instance, Eclipse:
When you have the above configuration and you try running the following program, you’ll get three warnings:
public static void main(String[] args)
throws Exception {
Connection c = DriverManager.getConnection(
"jdbc:h2:~/test", "sa", "");
Statement s = c.createStatement();
ResultSet r = s.executeQuery("SELECT 1 + 1");
r.next();
System.out.println(r.getInt(1));
}The output is, trivially
2
The warnings are issued on all of c, s, r. A quick fix (don’t do this!) is to suppress the warning using an Eclipse-specific SuppressWarnings parameter:
@SuppressWarnings("resource")
public static void main(String[] args)
throws Exception {
...
}After all, WeKnowWhatWeReDoing™ and this is just a simple example, right?
Wrong!
The right way to fix this, even for simple examples (at least after Java 7) is to use the effortless try-with-resources statement.
public static void main(String[] args)
throws Exception {
try (Connection c = DriverManager.getConnection(
"jdbc:h2:~/test", "sa", "");
Statement s = c.createStatement();
ResultSet r = s.executeQuery("SELECT 1 + 1")) {
r.next();
System.out.println(r.getInt(1));
}
}In fact, it would be great if Eclipse could auto-fix this warning and wrap all the individual statements in a try-with-resources statement. Upvote this feature request, please!
Great, we know this. What’s the deal with Java 8?
In Java 8, the contract on AutoCloseable has changed very subtly (or bluntly, depending on your point of view).
A resource that must be closed when it is no longer needed.
Note the word "must".
An object that may hold resources (such as file or socket handles) until it is closed. The close() method of an AutoCloseable object is called automatically when exiting a try-with-resources block for which the object has been declared in the resource specification header. This construction ensures prompt release, avoiding resource exhaustion exceptions and errors that may otherwise occur.
API Note:
It is possible, and in fact common, for a base class to implement AutoCloseable even though not all of its subclasses or instances will hold releasable resources. For code that must operate in complete generality, or when it is known that the AutoCloseable instance requires resource release, it is recommended to use try-with-resources constructions. However, when using facilities such as Stream that support both I/O-based and non-I/O-based forms, try-with-resources blocks are in general unnecessary when using non-I/O-based forms.
In short, from Java 8 onwards, AutoCloseable is more of a hint saying that you might be using a resource that needs to be closed, but this isn’t necessarily the case.
This is similar to the Iterable contract, which doesn’t say whether you can iterate only once, or several times over the Iterable, but it imposes a contract that is required for the foreach loop.
When do we have “optionally closeable” resources?
Take jOOQ for instance. Unlike in JDBC, a jOOQ Query (which was made AutoCloseable in jOOQ 3.7) may or may not represent a resource, depending on how you execute it. By default, it is not a resource:
try (Connection c = DriverManager.getConnection(
"jdbc:h2:~/test", "sa", "")) {
// No new resources created here:
ResultQuery<Record> query =
DSL.using(c).resultQuery("SELECT 1 + 1");
// Resources created and closed immediately
System.out.println(query.fetch());
}The output is again:
+----+ | 2| +----+ | 2| +----+
But now, we have again an Eclipse warning on the query variable, saying that there is a resource that needs to be closed, even if by using jOOQ this way, we know that this isn’t true. The only resource in the above code is the JDBC Connection, and it is properly handled. The jOOQ-internal PreparedStatement and ResultSet are completely handled and eagerly closed by jOOQ.
Then, why implement AutoCloseable in the first place?
jOOQ inverses JDBC’s default behaviour.
- In JDBC, everything is done lazily by default, and resources have to be closed explicitly.
- In jOOQ, everything is done eagerly by default, and optionally, resources can be kept alive explicitly.
For instance, the following code will keep an open PreparedStatement and ResultSet:
try (Connection c = DriverManager.getConnection(
"jdbc:h2:~/test", "sa", "");
// We "keep" the statement open in the ResultQuery
ResultQuery<Record> query =
DSL.using(c)
.resultQuery("SELECT 1 + 1")
.keepStatement(true)) {
// We keep the ResultSet open in the Cursor
try (Cursor<Record> cursor = query.fetchLazy()) {
System.out.println(cursor.fetchOne());
}
}With this version, we no longer have any warnings in Eclipse, but the above version is really the exception when using the jOOQ API.
The same thing is true for Java 8’s Stream API. Interestingly, Eclipse doesn’t issue any warnings here:
Stream<Integer> stream = Arrays.asList(1, 2, 3).stream(); stream.forEach(System.out::println);
Conclusion
Resource leak detection seems to be a nice IDE / compiler feature at first. But avoiding false positives is hard. Specifically, because Java 8 changed contracts on AutoCloseable, implementors are allowed to implement the AutoCloseable contract for mere convenience, not as a clear indicator of a resource being present that MUST be closed.
This makes it very hard, if not impossible, for an IDE to detect resource leaks of third party APIs (non-JDK APIs), where these contracts aren’t generally well-known. The solution is, as ever so often with static code analysis tools, to simply turn off potential resource leak detection:
| Reference: | A Subtle AutoCloseable Contract Change Between Java 7 and Java 8 from our JCG partner Lukas Eder at the JAVA, SQL, AND JOOQ blog. |
