What kind of path (absolute, relative, Windows, Unix) should there be inside a .getResource() parent

[Ramon F Herrera]

I am porting to NetBeans an application that was running fine under
JBuilder. There is one type of statement that refuses to be ported.

The application contains a lot of lines like this:

url = AnnualReportsDialog.class.getResource("images/Check Mark.gif");

Even the JBuilder tutorial has the same kind of file access relative
to some current or default directory:

ImageIcon image1 = new
ImageIcon(hello_world.HelloWorldFrame.class.getResource("openFile.png"));

When the "url" line above is reached, the getResource() fails.

I have tried several variations:

url = AnnualReportsDialog.class.getResource("C:\\images\\Check
Mark.gif");
url = AnnualReportsDialog.class.getResource("C:/images/Check
Mark.gif");

but they don't work.

Perhaps something has changed between JRE 1.4 and 1.6?

What is the more general solution to the problem of Java not having a
'chdir()'? My app runs on Windows but I would like to run in in *ix as
well.

Is there a way to place all those GIFs in some sort of resource, that
can be carried around different O/Ss and filesystem paths?

TIA,

-Ramon

 

[Andrew Thompson]

I am porting to NetBeans an application that was running fine under
JBuilder. There is one type of statement that refuses to be ported.

The application contains a lot of lines like this:

url = AnnualReportsDialog.class.getResource("images/Check Mark.gif");

Try..
url = AnnualReportsDialog.class.getResource("/images/Check Mark.gif");

Note the leading '/' means roughly 'the root of the classpath'.
...

Is there a way to place all those GIFs in some sort of resource, that
can be carried around different O/Ss and filesystem paths?

Sure. Put them in an images directory, jar it, add the jar
to the application's runtime classpath, and reference them
as above. So long as you are not using the default
classloader, the images should be located.

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200710/1

 

[Nigel Wade]

I am porting to NetBeans an application that was running fine under
JBuilder. There is one type of statement that refuses to be ported.

The application contains a lot of lines like this:

url = AnnualReportsDialog.class.getResource("images/Check Mark.gif");


Even the JBuilder tutorial has the same kind of file access relative
to some current or default directory:

ImageIcon image1 = new
ImageIcon(hello_world.HelloWorldFrame.class.getResource("openFile.png"));

When the "url" line above is reached, the getResource() fails.

I have tried several variations:

url = AnnualReportsDialog.class.getResource("C:\\images\\Check
Mark.gif");
url = AnnualReportsDialog.class.getResource("C:/images/Check
Mark.gif");

but they don't work.

Perhaps something has changed between JRE 1.4 and 1.6?

What is the more general solution to the problem of Java not having a
'chdir()'? My app runs on Windows but I would like to run in in *ix as
well.

Is there a way to place all those GIFs in some sort of resource, that
can be carried around different O/Ss and filesystem paths?

TIA,

-Ramon

That URL specifies that the resource to be loaded is in the directory "images"
relative to the location of the class file AnnualReportsDialog.class. So, if
the class file is in my/package/name/AnnualReportsDialog.class then the above
will attempt to open my/package/name/images/Check Mark.gif. If that class is
being loaded from a jar then the gif should be in the jar.

In NetBeans this means you should put it in the project directory
src/my/package/name/images. When you build the project the file ought to be
included in the jar under the same path, and therefore accessible to the
classloader. Similarly, if you create the directory src/images within the
project source then you can access that directory with the URI /images in your
code, i.e. AnyClass.getClass().getResource("/images/image.img"). Because it's
an absolute URI the actual class you use is irrelevent (provided you're not
being inventive with class loaders), and implicit use of this.getClass() (i.e.
just getClass().getResource() in a non-static context) should suffice.