Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Clean Up Your Mess: Managing Temp Files in Java Apps : Page 3

Creating and managing temporary files in a Java application can be a little tricky due to some open JVM bugs. Develop a workaround with some custom code and a clever design.


WEBINAR: On-demand Event

Unleash Your DevOps Strategy by Synchronizing Application and Database Changes REGISTER >

Implementation: Plugging a Hole, Fixing a Leak
To keep things simple, I wanted an API similar to the File class already in the JFC. I created a class, TempFileManager, to handle the creation of temporary files as well as the cleanup of existing files. The first method, createTempFile(String prefix, String suffix), shown in Listing 1, behaves just like the File's method to any callers. The internals are a bit different, however. The manager first checks to see if it has been initialized. If it hasn't, the manager generates a directory name relative to the system temporary directory and then creates a lock file for it. Finally the temp directory is created. Performing the steps in this order ensures that there is no race condition allowing another manager to delete the temp directory before the lock is created. The lock file is marked for deletion at exit, which will work since nothing in the JVM is holding an open reference to it. Finally, the method creates the temporary file that the user requested in the new directory.

The next important method in the TempFileManager isn't really a method at all, but rather a static initialization block. The JVM runs this block when the class is loaded for the first time. This ensures that the manager will have a chance to clean up any old temp files as soon as the application requests the class, and it does not require the application to tell the manager to perform this cleanup.

Within the static {} block in Listing 1, the manager obtains a list of the files in the temporary directory, using a file filter to get only directories that begin with the magic temp file manager prefix. For each directory found, a check is performed to find the lock file. If no lock file is found, the directory is recursively deleted using the utility method recursiveDelete(File rootDir). With this implementation of the manager, a single instance would clean up temporary files from any number of other applications using the same manager implementation.

Using the TempFileManager in an application is quite simple. To ensure that the temp file manager cleans up leaked files from a previous run, force the JVM to load the class:


This step is not required since generating a new temporary file will cause the manager to be loaded, but explicitly loading the manager can be useful for documentation purposes. To create a new temporary file, the call is almost identical to the JFC API:

File myTmp = TempFileManager.createTempFile("foo", ".bar");

Leak Plugged—Headache Avoided
With a solution designed and implemented, I was able to replace all calls to java.io.File#createTempFile(...) with calls to TempFileManager#createTempFile(...) and plug the file leak. No other code changes were necessary, and I didn't have to wait for Sun to close the open bugs. Although not perfect, this solution does prevent temporary files from growing to the point of being a problem on a user's system.

If you are running your application from a shell script or batch file, you could build upon this solution by also including a simple main(...) method in your implementation of TempFileManager and call it directly after your application's JVM exits. This would clean up the temp files instantly and still maintain the lock file safety required.

This is another example of a little bug that could cause big headaches if it is not solved before a project is released. Your users will thank you and you'll be able to sleep a little better at night knowing you won't get a call complaining of a full hard disk—at least not one caused by this application.

Michael Pilone is a software engineer and researcher for the U.S. Department of Defense at the Naval Research Laboratory. He also is Founder and CTO of Zizworks (http://www.zizworks.com), a Web-application and software development company.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date