getClass().getResource(String) and getResourceAsStream(String) use the class's location to look for resources. Appending a forward slash at the beginning makes it look at the root of the application package hierarchy.

For example, lets say the class MyClass is under com.mygame.mypackage. If the file you want is "image.png", you put it under com/mygame/mypackage/ and do MyClass.class.getResource("image.png") or MyClass.class.getResource("/com/mygame/mypackage/image.png").

This mostly depends on the classloader used but according to experience, this works with Jar files, applets, and webstart.

Yes, basically, only useful in certain situations, like having, what they call a "fat jar", meaning a jar which actually also contains the ressources.In that case its the only (?) way to access the stuff.

You have to set the settings properly. They're quite confusing at first. Also, you should make a "jardesc" file (2nd screen in the exporting process). This will save the exporting settings in a *filename*.jardesc file and allow you to automate all future exportings.

Yes, basically, only useful in certain situations, like having, what they call a "fat jar", meaning a jar which actually also contains the ressources.In that case its the only (?) way to access the stuff.

It works with loose files as well, not just those situations above. For example, if I have test.png in the same folder as a class file (in the default package in this particular example), I can do this to display it:

Seriously, that's the maven defaults (and sbt, and buildr, and gradle). It's not hard to change it in the config, but the defaults mean not having to write any of that config. What's really handy though is the separate directory per language, useful when you mix in groovy or jruby or scala...

on a serious note: even if you like fat jars, which I dont,you seriously wouldn't want a 800mb jar containing EVERYTHING, now would you ?apart from being horrible you couldn't even swap or change files anymore, without replacing the whole thing.Remember I'm talking in big-games-terms here, not your 5 min casual games with 10 images, 5MB total.

@ReBirth & Giovanni, perhaps your problem is you aren't refreshing when adding new images to the source? After I save an image, either new or edited, to my /src/res/ directory... In order to see the changes I have to right click on my project name(listing on the left side of eclipse window) and choose Refresh. This will copy everything in the src/* to the bin/*. Your resources should then be available to the build, and when exported the last Refresh will be included in the jar file.

its the same. difference is, then there are no src or bin folders, but a jar at the rootall paths remain the same, never using this weird getResource

Note: This is not how I think things have to be done, but I'm sure I don't follow some weird java conventions here. So what you are looking at is a project structure, in which someone just does what he thinks makes sense, not following standards.

its the same. difference is, then there are no src or bin folders, but a jar at the root

I was being a little pedantic, but my point was that this doesn't have to be true. Note sproingie (most likely) doesn't ship his unit tests with his actual product, yet they are contained in the source folder via src/test/**. Project layout doesn't have to map 100% to jar contents. You can have multiple source folders, like the example above (src/main and src/test) and only ship one of them, for example. You could also put only the class files into your jar, and use getResource() to refer to any images in resources/ subfolders outside of that jar.

Quote

all paths remain the same, never using this weird getResource

But like I mentioned in my earlier post, getResource() will work with both flat files and jar contents. Same "path" and everything.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org