InputStream.getResourceAsStream() giving null pointer exception

Question

The line persistenceProperties.load(is); is throwing a nullpointerexception in the following method. How can I resolve this error?

Answer 1

ClassLoader.getResourceAsStream() loads resources as it does for loading classes. It thus loads them from the runtime classpath. Not from the source directories in your project.

Your class Main is in the package maintest, and its name is thus maintest.Main. I know that without even seeing the code because Main.java is under a directory named maintest, which is at directly under a source directory.

The persistence.properties file is directly under a source directory (src/test/resources). At runtime, it's thus at the root of the classpath, in the default package. Its name is thus persistence.properties, and not src/test/samples/peristence.properties. So the code should be

 getClass().getClassLoader().getResourceAsStream("persistence.properties");

Nothing will ever be loadable from the samples directory, since thisdirectory is not under any source directory, and is thus not compiled by Eclipse, and is thus not available to the ClassLoader.

Answer 2

InputStream is = this.getClass().getResourceAsStream("/package_name/property file name")

PropertyFileOject.load(is)

In my case error was due to maven was not treating my config folder inside src/main/java as source folder.

Recreated config package in src/main/java ..Copied files to it and re-compiled using maven. Files were there in target directory and hence in war. Error resolved.

Answer 3

Your IDE works with two different scopes:

• production scope: src/main/java + src/main/resources folders and
• test scope: src/test/java + src/test/resources

Seems you are trying to execute you program from production scope, while persistence.properties file is placed into test scope.

How to fix:

• Place your test into src/test/java or
• Move persistence.properties into src/main/resources

Answer 4

Short answer: Move persistence.properties to src/main/resources, have both Main.java and TestFunctions.java in src/main/java, and use

 getClass().getClassLoader().getResourceAsStream("persistence.properties");

to load the properties file.

Long answer with an explanation:

As others have hinted at - in a Maven project structure, you (typically) have two directory trees: /src/main and /src/test. The general intent is that any "real" code, resources, etc should go in /src/main, and items that are test-only should go in /src/test. When compiled and run, items in the test tree generally have access to items in the main tree, since they're intended to test the stuff in main; items in the main tree, however, do not typically have access to items in the test tree, since it's generally a bad idea to have your "production" code depending on test stuff. So, since Main.java depends on TestFunctions.java, and TestFunctions.java depends on persistence.properties, if Main is in src/main then both TestFunctions and persistence.properties need to be as well.

Answer 5

I recently had the same problem and came upon the solution that I had to put my resources in a path the same way organized as where was getClass().getResourceAsStream(name) situated. And I still had a problem after doing that. Later on, I discovered that creating a package org.smth.smth only had created a folder named like that "org.smth.smth" and not a folder org with a folder smth and a folder inside smth... So creating the same path structure solved my problem. Hope this explanation is understandable enough.

Answer 6

Two things:

First, try a path of test/samples/... or /test/samples/...

Secondly, and much more importantly, don't ever, ever, ever write this:

try {
    // some stuff
} catch (IOException ignored) {}

All this says is: do some stuff, and if it goes wrong, then fail silently. That is never the right thing to do: if there's a problem, you want to know about it, rather than madly rushing on as if nothing had happened. Either do some sensible processing in your catch block, or else don't have the try/catch and add a throws IOException to your method signature so it can propagate upwards.

But at the moment, you're just sweeping things under the carpet.