CODEWITHSUNDEEP
javaresources
Bruno Giannotti
Bruno Giannotti

Reputation: 323

How to correctly setup resources in a exportable library

In a library I made, I have the following line to retrieve my resources:

private static final File fragment = new File(DefaultShader.class.getClassLoader().getResource("file.txt").getFile());

But when I export this library to a JAR and attempt to use it in another application, when this same line is read internally I get an I/O error because it's trying to access the JAR.

java.io.FileNotFoundException: file:\C:\Users\me\test\libs\lib.jar!\file.txt

Nodejs would make this easier by providing methods that returns the runtime location path of a script, apparently there is not an equivalent in Java or just couldn't find it. How can I get around this issue?

Upvotes: 0

Views: 32

Answers (1)

VGR
VGR

Reputation: 44335

Never call the getFile method of URL. It does not return a valid file name. It only returns the path portion of a URL.

A resource embedded in a .jar file is not a File and you cannot refer to it as a File.

Fortunately, you don’t need a File object. You can read it directly using getResourceAsStream:

DefaultShader.class.getResourceAsStream("/file.txt")

Obviously, you should not store an InputStream in a static final field. But you can easily make a method instead:

private static InputStream readFileData() {
    return DefaultShader.class.getResourceAsStream("/file.txt");
}

Be aware that resources should be placed in packages, just like classes. Placing a resource in the root of a .jar is like writing a file to a drive’s root directory or the user’s home directory: if any other program chooses to use the same filename, the results for both programs will be problematic, to say the least.

Similarly, if your resource is in the root of your .jar, and another library also happens to store a resource with the same name in the root of its own .jar, there will be a conflict, and it may or may not be your resource which gets loaded by the getResource* methods, depending on the current classpath definition. (This concern doesn’t apply to Java 9+ modular programs, but it’s still a good idea to keep resources in packages.)

The practice of putting a resource in the same package as the class that uses it is considered a good practice by Java SE: the getResource and getResourceAsStream methods are designed to expect it in the same package as the class by default. If the string argument does not start with a slash, those methods assume it’s in the same package.

This looks for file.txt in the same package as the DefaultShader class:

DefaultShader.class.getResourceAsStream("file.txt")

Whereas this will look for file.txt in the root of every .jar in the classpath:

DefaultShader.class.getResourceAsStream("/file.txt")

Upvotes: 1

Related Questions