org.springframework.boot.loader.jar.JarFile doesn't actually close when close() is called

[kjperkin]

Hi! I was having trouble with some JUnit test cases where the tests would fail to clean up their temporary directories after running. I tracked down the issue to three things:

1. There doesn't appear to be a way to close a JarFileArchive
2. org.springframework.boot.loader.LaunchedURLClassLoader doesn't close open files when close() is called
3. Even if I could close a JarFileArchive, it contains an instance of org.springframework.boot.loader.jar.JarFile. All instances of org.springframework.boot.loader.jar.JarFile fail to close properly when close() is called on them.

This issue describes item (3). Please let me know if more information is needed.

Description

The JarFile class in org.springframework.boot.loader.jar doesn't close correctly. I verified this by pausing execution after closing the file and checking if the file handle was closed. It was not. With a regular java.util.jar.JarFile, calling close() immediately closes the OS-level file handle.

Analysis

I suspect this is because org.springframework.boot.loader.jar.JarFile doesn't call super.close(). The offending code:

@Override
public void close() throws IOException {
    this.rootFile.close();
}

Failing test case

Here is a JUnit test case that fails on my system. I figure out if the JarFile is closed by trying to delete it's containing folder. On Windows, this will fail if the JarFile is still open.

import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.TemporaryFolder;
import org.springframework.boot.loader.jar.JarFile;
import org.springframework.boot.loader.tools.JarWriter;

import java.io.File;
import java.io.IOException;

import static org.junit.Assert.assertFalse;

public class Example {
    @Rule
    public TemporaryFolder tmpDir = new TemporaryFolder();

    @Test
    public void testJarFileCloses() throws IOException {
        File tmp2 = tmpDir.newFile();
        JarWriter ok = new JarWriter(tmp2);
        ok.close();

        java.util.jar.JarFile jf2 = new java.util.jar.JarFile(tmp2);
        jf2.close();

        File tmp = tmpDir.newFile();
        JarWriter jarWriter = new JarWriter(tmp);
        jarWriter.close();

        JarFile jf = new JarFile(tmp);
        jf.close();

        tmpDir.delete();
        assertFalse("tmpDir.delete() should be able to delete the directory", tmpDir.getRoot().exists());
    }

}

System information

java -version

java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

IDE information

IntelliJ IDEA 2017.1
Build #IU-171.3780.107, built on March 22, 2017
Licensed to Kevin Perkins
Subscription is active until August 25, 2017
JRE: 1.8.0_112-release-736-b13 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0

OS Version Information

OS Name	Microsoft Windows 10 Pro
Version	10.0.14393 Build 14393
System Type	x64-based PC

[philwebb]

I'm having some trouble getting my Windows VM running. Are you able to reduce the test case to a single item that's locking the file? I assume that just the last four lines are enough? Is that correct?

[kjperkin]

I think you'd want the last 7 lines so that a valid jar file is created.

I think I wrote those first 5 lines so that it would be possible to verify that java.util.jar.JarFile closes it's file handle as soon as close is called by stepping through those lines while watching the file handles using a tool like Process Explorer.

[wilkinsona]

Thanks, @kjperkin. I've reproduced this on Windows 7 and can confirm that the missing call to super.close() is indeed the problem.