jenkinsci/lib-file-leak-detector

current running jar leak

cristyrye opened this issue · 2 comments

I want to get a file from the current running jar, and this is my code:

public static void extractTextResource(Object obj, String includedFile, String outputFile) {

String inputFile = "/includes/" + includedFile; //this is the file location in JAR
StringBuilder sb = new StringBuilder();
InputStream inputStream = null;
	try {
		inputStream = obj.getClass().getResourceAsStream(inputFile); //this is line 33
		try (BufferedInputStream bufferedInputStream = new BufferedInputStream(inputStream); Scanner scanner = new Scanner(bufferedInputStream);) {
			while (scanner.hasNextLine()) {
				sb.append(scanner.nextLine());
				sb.append(System.lineSeparator());
			}
		} catch (IOException e) {
			e.printStackTrace();
		}
	} finally {
		try {
			if (inputStream != null) {
				inputStream.close();
			}
		} catch (IOException e) {
			e.printStackTrace();
		}
	}
	Files.write(Paths.get(outputFile), sb.toString().getBytes());

}

File leak detector result:
1 descriptors are open
#1 D:\application.jar by thread: main on Mon May 15 17:38:12 EEST 2017
at java.util.zip.ZipFile.(Unknown Source)
at java.util.jar.JarFile.(Unknown Source)
at java.util.jar.JarFile.(Unknown Source)
at sun.net.www.protocol.jar.URLJarFile.(Unknown Source)
at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source)
at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source)
at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source)
at sun.net.www.protocol.jar.JarURLConnection.getInputStream(Unknown Source)
at java.net.URLClassLoader.getResourceAsStream(Unknown Source)
at java.lang.Class.getResourceAsStream(Unknown Source)
at com.company.FilesUtils.extractTextResource(FilesUtils.java:33)

Is my code wrong? is file leak detector wrong? is there a bug in Java Library?

After some tests I found out that even if I extract multiple resources from the jar, only 1 descriptor is open. For 5 extracted files there should be 5 file leaks, but there is just one. I think now it is a file leak descriptor bug.

java itself opens the jar, but does not close it any more. So it is more a false positive, see the exclude feature for how you can remove such things from the report