Introduction

Reading a resource from inside a JAR is not the same as opening a normal filesystem path. Once a file is packaged into the application's classpath, you should load it as a classpath resource through Class or ClassLoader, usually as an InputStream.

Think in Terms of Classpath Resources

A file inside a JAR is not a standalone file sitting on disk in the ordinary sense. It is part of the classpath. That means code such as this is usually the wrong model:

// Often wrong for JAR-packaged resources
new File("src/main/resources/config.txt")

That may work in development when the source tree is visible, but it usually fails once the application is packaged and run from a JAR.

Use getResourceAsStream()

The normal answer is to load the resource as a stream:

1import java.io.BufferedReader;
2import java.io.IOException;
3import java.io.InputStream;
4import java.io.InputStreamReader;
5
6public class Main {
7    public static void main(String[] args) throws IOException {
8        try (InputStream is = Main.class.getResourceAsStream("/config.txt")) {
9            if (is == null) {
10                throw new IllegalStateException("Resource not found");
11            }
12
13            try (BufferedReader reader = new BufferedReader(new InputStreamReader(is))) {
14                reader.lines().forEach(System.out::println);
15            }
16        }
17    }
18}

With Class.getResourceAsStream(), the leading / means "start from the classpath root."

ClassLoader.getResourceAsStream() Is Slightly Different

You can also load through the class loader:

InputStream is = Main.class.getClassLoader().getResourceAsStream("config.txt");

The path form is slightly different here:

• 'Class.getResourceAsStream("/config.txt") uses a leading slash for an absolute classpath lookup'
• 'ClassLoader.getResourceAsStream("config.txt") does not use the leading slash'

Both are valid, but mixing their path rules is a common source of null results.

Reading Text Safely

If the resource is text, wrap the stream in a reader and choose the charset explicitly when appropriate:

1import java.io.BufferedReader;
2import java.io.InputStream;
3import java.io.InputStreamReader;
4import java.nio.charset.StandardCharsets;
5
6try (InputStream is = Main.class.getResourceAsStream("/config.txt");
7     BufferedReader reader = new BufferedReader(
8         new InputStreamReader(is, StandardCharsets.UTF_8))) {
9
10    String line;
11    while ((line = reader.readLine()) != null) {
12        System.out.println(line);
13    }
14}

This avoids platform-default charset surprises.

If You Need Bytes Instead of Text

Not every resource is text. For images, binary blobs, or templates you want to pass elsewhere, read the bytes directly:

1import java.io.InputStream;
2
3try (InputStream is = Main.class.getResourceAsStream("/logo.png")) {
4    if (is == null) {
5        throw new IllegalStateException("Resource not found");
6    }
7
8    byte[] data = is.readAllBytes();
9    System.out.println(data.length);
10}

The loading mechanism is the same even though the interpretation is different.

Do Not Assume a Real Filesystem Path Exists

Another common mistake is asking the resource for a File path and then treating it like a normal filesystem location. That can break when the application actually runs from a packaged JAR because the resource is inside the archive, not available as a regular external file.

If a library absolutely requires a real file path, the usual workaround is to copy the resource stream to a temporary file first.

Package Placement Matters

The resource must actually be included in the built JAR. In a standard Java or Maven project, resources typically live under a classpath-managed directory such as src/main/resources. If the build never packages the file, your loading code can be correct and still return null.

That is why resource-loading bugs are often half code issue and half build configuration issue.

Common Pitfalls

• Trying to read a JAR resource with new File(...) instead of classpath APIs.
• Mixing up Class.getResourceAsStream() and ClassLoader.getResourceAsStream() path rules.
• Forgetting to check for null when the resource is missing.
• Relying on the default character encoding for text resources.
• Assuming a resource inside a JAR has a normal filesystem path you can always pass to file-based APIs.

Summary

• Files inside a JAR should be treated as classpath resources, not normal filesystem files.
• Use getResourceAsStream() or getClassLoader().getResourceAsStream() to load them.
• Be careful about path syntax differences between Class and ClassLoader.
• Read text with an explicit charset when possible.
• If a library needs a real file path, copy the resource stream to a temporary file first.