1. Overview
It’s important to ensure the proper closing of IO streams within the realm of Java IO operations. This is significant for resource management and code robustness.
In this tutorial, we’ll explore in detail why it’s necessary to close IO streams.
2. What Happens When IO Streams Aren’t Closed?
It’s always a good practice to explicitly close IO streams right after finishing all operations on them. Neglecting to close them may cause various issues.
In this section, we’ll take a look at these issues.
2.1. Resource Leakage
Whenever we open an IO steam, it always takes up a bit of system resources. The resources aren’t released until the IO stream close() method is called.
Certain IO stream implementations can close themselves automatically within their finalize() method. The finalize() method is invoked whenever the garbage collector (GC) is triggered.
However, there’s no guarantee that the GC will be invoked, nor on when it will be called. It’s possible that the resources run out before the GC is called. Therefore, we shouldn’t solely depend on GC to reclaim system resources.
2.2. Data Corruption
We often wrap a BufferedOutputStream around an OutputStream to provide buffered capability to reduce the overhead of each write operation. It’s a common practice and aims to improve the performance in writing data.
The internal buffer within the BufferedOutputStream is a staging area for data that is for temporary storage. Whenever the buffer reaches a certain size or the flush() method is called, the data will be written to the destination.
After we finish writing data to the BufferedOutputStream, it’s possible that the last chunk of data isn’t yet written to the target, leading to data corruption. Calling the close() method invokes flush() to write the remaining data in the buffer.
2.3. File Locking
When we write data to a file using FileOutputStream, some operating systems such as Windows hold the file in our application. This prevents other applications from writing or even accessing the file until the FileOutputStream is closed.
3. Closing IO Streams
Now let’s take a look at a few approaches for closing Java IO streams. These approaches help avoid the issues we discussed above and ensure proper resource management.
3.1. try-catch-finally
This is the traditional way of closing IO streams. We close IO streams in the finally block. This ensures the close() method is invoked no matter whether the operations are successful or not:
InputStream inputStream = null;
OutputStream outputStream = null;
try {
inputStream = new BufferedInputStream(wrappedInputStream);
outputStream = new BufferedOutputStream(wrappedOutputStream);
// Stream operations...
}
finally {
try {
if (inputStream != null)
inputStream.close();
}
catch (IOException ioe1) {
log.error("Cannot close InputStream");
}
try {
if (outputStream != null)
outputStream.close();
}
catch (IOException ioe2) {
log.error("Cannot close OutputStream");
}
}
As we’ve demonstrated, the close() method could raise an IOException as well. Therefore, we must put another try-catch block in the finally block when closing the IO streams. This process becomes cumbersome when there are numerous IO streams we have to deal with.
3.2. Apache Commons IO
Apache Commons IO is a versatile Java library that provides utility classes and methods for IO operations.
To use it, let’s include the following dependency in our pom.xml:
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>2.15.1</version>
</dependency>
The Apache Commons library simplifies complex tasks such as closing IO streams in a finally block:
InputStream inputStream = null;
OutputStream outputStream = null;
try {
inputStream = new BufferedInputStream(wrappedInputStream);
outputStream = new BufferedOutputStream(wrappedOutputStream);
// Stream operations...
}
finally {
IOUtils.closeQuietly(inputStream);
IOUtils.closeQuietly(outputStream);
}
IOUtils.closeQuietly() efficiently closes IO streams without the need for null checking and taking care of exceptions that occur during the closing process.
Besides IOUtils.closeQuietly(), the library also provides the AutoCloseInputStream class to automate the closure of the wrapped InputStream:
InputStream inputStream = AutoCloseInputStream.builder().setInputStream(wrappedInputStream).get();
byte[] buffer = new byte[256];
while (inputStream.read(buffer) != -1) {
// Other operations...
}
The example above reads data from the InputStream. AutoCloseInputStream closes the InputStream automatically as soon as it reaches the end of the input, which is determined by getting -1 from the read() method in the InputStream. In this case, we don’t even need to call the close() method explicitly.
3.3. try-with-resources
The try-with-resources block was introduced in Java 7. It is considered the preferred way of closing IO streams.
This approach allows us to define resources within the try statement. A resource is an object that must be closed when we finish using it.
For instance, classes such as InputStream and OutputStream that implement the AutoClosable interface are used as resources. They’ll be automatically closed after the try-catch block. This eliminates the need to call the close() method in the finally block explicitly:
try (BufferedInputStream inputStream = new BufferedInputStream(wrappedInputStream);
BufferedOutputStream outputStream = new BufferedOutputStream(wrappedOutputStream)) {
// Stream operations...
}
Further advancements emerged in Java 9, refining the try-with-resources syntax. We can declare the resource variables ahead of the try-with-resources block, and specify their variable names directly in the try statement:
InputStream inputStream = new BufferedInputStream(wrappedInputStream);
OutputStream outputStream = new BufferedOutputStream(wrappedOutputStream);
try (inputStream; outputStream) {
// Stream operations...
}
4. Conclusion
In this article, we examined various strategies for closing IO streams, from traditional methods invoking the close() method in the finally blocks to more streamlined approaches offered by libraries like Apache Commons IO and the elegance of try-with-resources.
With a spectrum of various techniques, we can choose the approach that aligns best with our codebase and ensures smooth and error-free IO operations.
As usual, the source code presented in the article is available over on GitHub.
