4th International Conference on Principles and Practices ... - MADOC

[4]. The fact that the Java framework has no way of explicitly
releasing memory 1 , but has numerous ways of closing other
resources explicitly 2 , supports this view.
The fact that Java’s finalizers are not guaranteed to be run in a
timely fashion would seem to limit their usefulness. Even more
limiting, however, is that finalizers are in fact not guaranteed to
be run at all [9][3]. An object’s finalizer is only guaranteed to be
run if the object is garbage collected, and garbage collection is not
guaranteed to happen [4]. It is entirely possible for a program to
exit without any of its objects being garbage collected or
finalized. Java does provide a way to force objects to be finalized
on exit 3 , but the functionality has been deprecated since Java 1.2,
as it has been deemed unsafe. Without any accepted way to
guarantee finalization, exactly how finalization is at all useful
becomes a valid question.
Because finalization’s usefulness is limited, Java code must
manually release all scarce resources. Java does not make this job
simple. While releasing a resource typically boils down to a
single method call, the exact call is not standardized across the
Java libraries. Most resources provide a close() method,
including Socket, InputStream, Connection, etc. However, a few
resources stray from that pattern, such as the AWT Window class,
which provides the dispose() method. Even those classes which
do provide a close() method are not truly consistent, because Java
does not have a single, unified interface for closing resources.
The closest the library comes to a unified interface is Closeable.
The Closeable interface is implemented by all resources in the
java.io package. However, outside the java.io package, few
resources implement the Closeable interface, and so many
resources cannot be treated as instances of Closeable. The net
effect of what are in fact fairly minor inconsistencies is that there
is no straightforward way to release all resources in an identical
manner, which complicates any attempt at automated resource
deallocation.
1.4 Releasing Resources
Dependencies are inherent in the very nature of resources. A
JDBC PreparedStatement object has no logical meaning in the
absence of an associated Connection object. Similarly, the input
and output streams associated with a network socket have no
further meaning once the socket they are built upon closes. Upon
inspection, it becomes clear that there are many such
dependencies, and they are applicable to all sorts of resources.
While at first it might seem logical that when a resource closes,
any resources which depend on that resource will also close
automatically, this cannot be safely assumed in the general case.
Any behavior which is not defined is undefined, axiomatically.
Undefined behavior cannot be trusted to act consistently, and the
Java documentation is usually quiet when it comes to automatic
resource closure. One might assume that when a database
connection closes, any statements tied to that connection will also
1 Java does provide a way to request that the garbage collector be
immediately run, but this practice is discouraged, and is not
guaranteed to free any memory, only to make an attempt.
2 Various calls are used to close resources, including
Closeable.close(), Window.dispose(), Connection.close(), etc.
3 Runtime.runFinalizersOnExit()
close. However, the Java 1.5 API documentation makes no such
claim [16]. 4 Accordingly, it falls on the programmer to explicitly
close any open statements along with the database connection.
Likewise, the API documentation does not state that closing a
socket automatically closes its associated streams, which leaves
this task to the programmer. In fact, the recommended method of
closing multiple dependent resources is to close them manually,
one at a time [4].
Whenever the documentation is silent about whether a resource
closing will cause any dependent resources to close, it is best to
assume nothing, and treat the dependent resources as potentially
unusable. In such a case, the only logical thing to do with the
dependent resources is to close them as well. When a socket is
closed, the programmer should immediately close the associated
input and output streams. In fact, this should be done before the
socket is closed [4]. It is interesting to note that in the Java 1.5
implementation provided by Sun, closing a stream associated with
a socket actually will close the socket [10], but this behavior is
unreliable. It is not guaranteed between Java versions – in fact it
is a recent change – and it is undocumented, which means other
Java implementations may not exhibit the same behavior.
1.5 Related Work
Finalizers were introduced into Java as a way to guarantee
cleanup [8], but it has been shown that finalizers fail in their task.
Stack-bound objects with destructors have been given thorough
attention in C++ [15], but such approaches are not applicable to
Java, due to its lack of stack-bound objects.
C# and .NET introduced the IDisposable interface, which is used
throughout the .NET framework. This provides the unifying
interface missing from Java. C# also introduced the using
keyword (coupled with the IDisposable interface) to simplify
resource management [7]. The using construct eliminates the
need for try-finally blocks when releasing resources, and even
automates the resource release. One drawback to applying this
technique to Java is that it requires language-level support, and so
requires a language extension. The second issue is that it requires
IDisposable, or an equivalent unified interface, to work.
Czajkowski provided a thorough treatment of the area of resource
allocation and usage monitoring [6]. However, the methods
presented are not applicable to releasing resources. The methods
do not eliminate the need for nested try-finally blocks when
releasing resources.
Weimer delved deeply into the issue of releasing resources [17]
using compensations, arbitrary pieces of code that are executed to
restore invariants. The framework presented by Weimer stores
these compensations on a stack, and the entire stack is typically
executed at once. However, compensations require changes to the
Java language itself, to add closures and an extended syntax.
Compensation stacks are also less flexible than the resource tree
model we will introduce in the next section.
4 The JDBC spec states that closing a Connection object closes
the associated Statement objects, although this is not reflected in
the more general Java 1.5 API documentation. The JDBC spec
states, however, that Statement and ResultSet objects should be
explicitly closed as soon as possible, implying that the
automatic closure is a fallback mechanism only.
115