Loading Images from a project's directory

Shared Code
#1

Very simple,

File file = new File("images/img.png"); //needs to be an "image" folder in the project folder
try {
   Image img = ImageIO.read(new File(file.toURI()));
} catch (Exception e) {
    
}
#2

Don’t ever use File to load resources:


BufferedImage image = ImageIO.read(getClass().getClassLoader().getResourceAsStream("images/img.png"));

getResourceAsStream(String) searches from the working directory, aka the bin folder in Eclipse/Netbeans or the root of the JAR file if run as stand-alone/applet.

#3

Why ?

I always use this.

#4

Try it in an applet, or webstart.

#5

File will not work when the resource is in a JAR file. Also, File uses a system dependent way for resolving relative paths. It is best to use a getResource(String) because it has 1 set behavior for all systems plus it can also return a URL/InputStream for resources inside ZIP/JAR files :slight_smile:

#6

Maybe anyone know why eclipse spits java.lang.NullPointerException then using getResource(String) or getResourceAsStream(String). Then runing from jar everthing works perfectly.

WorldIcon=new ImageIcon(getClass().getResource("img/world.gif"))
#7

my question was of course rhetorical, I just wanted you guys to make it clear.
Since I never use Applets or Webstarts and in fact only use relative file paths; so “never” seems harsh =D

#8

Using getClass().getResource(String) without a leading forward slash makes it look relative to that Class’s package.

#9

I tend to support both filesystem loading and classpath loading myself; gives freedom between “development mode” (in which I can set a working directory for the project in the IDE and switch that around when I’m experimenting) and “deployment mode” (all resources in the game jar). Something like:


InputStream is = null;

File fp = new File("somepath/somefile.png");

if(fp.isFile()){
  is = new FileInputStream(fp);
} else {
  is = getClass().getClassLoader().getResourceAsStream("somepath/somefile.png");
}

Insert exception handling and resource closing code. As an added “bonus” this strategy gives me the opportunity to override resources in the jar without having the replace them, which helps to debug problems with game resources in a more “live environment” - for example I can instruct someone that is testing to put a piece of game script or whatever in a specific place to see if that changes anything, without having to provide an updated jar first.

#10

Putting that directory in the classpath before the jars has exactly the same effect with resource loading. I do this all the time for config files in my own apps.

#11

For Jar files I always use:


Image i = new ImageIcon("directory").getImage();

It works with a jar file but the image folder has to be in the directory of the jar and not inside it…

#12

That’s because the String argument to ImageIcon always names a file. It also has a version that takes a URL, so you can say


Image i = new ImageIcon(getClass().getResource(path)).getImage();

Mind you I’d check that getClass().getResource(path) wasn’t null first.

#13

I am strongly against the usage of ImageIcon because it’s an ugly hack that internally just does:


Toolkit.getDefaultToolkit().getImage(...);

I advise you use javax.imageio.ImageIO:


ImageIO.read(URL);