Paul Clapham wrote:If you want to use that code as is, then you put the jpg file into the same folder (inside the jar) as the file which is trying to use the jpg. It's a relative URL so that means it's relative to the class which is getting the resource. Alternatively put a "/" before the URL to make it absolute, then put the jpg into the root folder of the jar.
But you mentioned a "src" folder... does that mean that your classes are in a package named "src"? Or does it mean that you're talking about how things are arranged in your IDE? If it's the former, then you should start looking at how things are arranged in the jar file after you produce it instead.
Mike London wrote:However, if I then put the MyImage.jpg into a JAR file and put that same JAR file in the root of the src folder (same folder as the code is in, no packages currently for simplicity), then I get the 'null' with or without leading slashes.
Paul Clapham wrote:
Mike London wrote:However, if I then put the MyImage.jpg into a JAR file and put that same JAR file in the root of the src folder (same folder as the code is in, no packages currently for simplicity), then I get the 'null' with or without leading slashes.
Now I'm confused. Why would you do that? Normally when people ask this question (and it's a very frequent question) it's because they have generated a jar file containing their application, and they want to use resources which they packaged along with the Java classes in that jar.
However if you really want a separate jar containing only your images, you have to make sure that it's in your classpath. Then the rules for the getResource() method apply, because getResource goes through all of the classpath roots.
Tony Docherty wrote:As Paul has said if the code is running from the src folder and not from the jar then the contents of the jar will not be available unless you have explicitly added the jar file to the classpath used when the program is launched.
I must say I've never tried to use getResource() or getResourceAsStream() when my classes haven't been in a package but I assume it works the same as if they are in a package.
Sorry for my apparent confusion. Since the standalone image file works fine with getReseourcAsStream (in the src) folder (or using an explicit path) when the program is running, doesn't that mean it's in the CLASSPATH?
Are you saying I should put the Java code that accesses the text file or image resource into the JAR as well?
Tony Docherty wrote:
Sorry for my apparent confusion. Since the standalone image file works fine with getReseourcAsStream (in the src) folder (or using an explicit path) when the program is running, doesn't that mean it's in the CLASSPATH?
The way it works is the class delegates the search to its classloader so it's up to the classloader that loaded the class to decide where to look. I believe the default classloader will look on the file system and in any locations/jars that are on the classpath. The resource to be loaded doesn't need to be on the classpath as long it is reachable ie if the path is relative then there is a relative path from somewhere on the classpath that locates a resource with the given name.
The problem you have is you have packaged the files in a jar and this jar is not on the classpath so the resources are no longer directly visible to the file system and the jar is not explicitly searched as it's is not on the classpath.
Are you saying I should put the Java code that accesses the text file or image resource into the JAR as well?
No I'm saying you need to add the jar to the classpath. You can do this by adding it to the classpath specified when running java.exe.
If you do put the code into the jar then when you run the code in the jar the jar is on the classpath so that will also work.
Stephan van Hulst wrote:What IDE are you using?
In NetBeans, right-click the Libraries node of your project, and click "Add Jar/Folder...". In Eclipse, right-click your project, go to "Build Path" and click "Add External Archives...". Find the jar that contains your resources and your code should now work.