getResource( path) fails in Jar

[Tom Blough]

I've downloaded a project from sourceforge (http://jdraw.sourceforge.net) and have made some modifications to it. The program has a call to getClass().getClass().getClassLoader().getResource( path ) where path is "jdomain/jdraw/images" to preload some image files. This works fine when executing within Eclipse and returns the URL encoded path "file:/C:/Documents%20and%20Settings/tblough/My%20Documents/Programming%20Projects/JDraw/bin/jdomain/jdraw/images".

When I make an executable jar of my project, this same call returns null. I've also tried this with the stock code and get the same results. I've verified the images are included in the jar, and the path is the same (and all lowercase). This is being compiled under 1.6.1. The funny thing is that the same code (I assume it's the same code) that is in an executable jar (compiled under 1.4) that comes with the source package works correctly.

The program has a splash screen that is loaded with ResourceLoader.getImage( "jdomain/jdraw/images/logo.png" ) and this works in both cases. ResourceLoader seems to find the specified file on the same path within the Jar without problems, but getResource( "jdomain/jdraw/images" ) is returning null when executed from within the jar.

Any ideas?
[ August 05, 2008: Message edited by: Tom Blough ]

[Maneesh Godbole]

Originally posted by T. Blough:
I've downloaded a project from sourceforge (http://jdraw.sourceforge.net) and have made some modifications to it. The program has a call to getClass().getClass().getClassLoader().getResource( path ) where path is "jdomain/jdraw/images" to preload some image files. This works fine when executing within Eclipse and returns the URL encoded path "file:/C:/Documents%20and%20Settings/tblough/My%20Documents/Programming%20Projects/JDraw/bin/jdomain/jdraw/images".

When I make an executable jar of my project, this same call returns null. I've also tried this with the stock code and get the same results. I've verified the images are included in the jar, and the path is the same (and all lowercase). This is being compiled under 1.6.1. The funny thing is that the same code (I assume it's the same code) that is in an executable jar (compiled under 1.4) that comes with the source package works correctly.

The program has a splash screen that is loaded with ResourceLoader.getImage( "jdomain/jdraw/images/logo.png" ) and this works in both cases. ResourceLoader seems to find the specified file on the same path within the Jar without problems, but getResource( "jdomain/jdraw/images" ) is returning null when executed from within the jar.

Any ideas?

Welcome to the ranch Tom !

I had faced a similar problem once. Eventually I identified the cause to be the case confusion in the file name (logo.png and logo.PNG). Can you confirm that this is not happening in your case?

While you are at it, could you also please adjust your display name to confirm with the naming policy?
You can do it by clicking here

[Tom Blough]

Originally posted by Maneesh Godbole:

Eventually I identified the cause to be the case confusion in the file name (logo.png and logo.PNG). Can you confirm that this is not happening in your case?

The files are indeed correctly cased (snip from Jar listing):

    testing: jdomain\jdraw\images\antialias_off.png   OK
    testing: jdomain\jdraw\images\antialias_on.png   OK
    testing: jdomain\jdraw\images\background.gif   OK
    .
    .
    .

And like I said it finds them correctly when running under Eclipse, but not when running from an executable jar exported from Eclipse. Also, the call that has the problem is returning null for a URL based on the path portion "jdomain/jdraw/images" and not a specific image file so I don't know if that is significant.

Originally posted by Maneesh Godbole:

While you are at it, could you also please adjust your display name to confirm with the naming policy?

I used to be a member here 5 years ago, and I could not remember the email I registered under. When attempting to re-register, it would not let me register with my previous screen name of "Tom Blough", so I used "T. Blough" (which, by the way, DOES confirm with your naming policy). It's interesting that once registered, I can CHANGE my screen name to my previous one.

[Tom Blough]

Well, it took a while to track this one down. getClass().getClassLoader().getResource() to obtain a URL to a directory worked fine until the app was jar-ed. When run form the Jar, the call returned null on the path, even though a listing of the Jar file showed the all the files in the Jar with the correct path.

The problem resulted because the path itself did not exist in the jar. The files with the path existed, but not the path itself. I was using the "Runnable JAR File" export command in Eclipse. When I tried the older export "Jar File" to create the jar, I noticed a check box for "add directory entries" and that was the solution. The Jar file needed the directory entry by itself in the jar for getResource() to return the URL for the path.

Now off to the "Runnable Jar File" guys to add a directory entries to that tool.

[Norm Radder]

That's interesting, you can put an entry in a jar file for a directory.
How do you do that with the jar command?
What happens if you unzip it with the Winzip command?

[Maneesh Godbole]

Originally posted by Tom Blough:

.. (which, by the way, DOES confirm with your naming policy).

Nah!
Its our naming policy; you included.
Thanks for the name change.


[ August 05, 2008: Message edited by: Maneesh Godbole ]

[Tom Blough]

Originally posted by Norm Radder:
That's interesting, you can put an entry in a jar file for a directory.
How do you do that with the jar command?
What happens if you unzip it with the Winzip command?

Norm,

It seems that Sun's Jar command does this by default, but Eclipse and a few others do not. I Googled and found a Kaffe forum entry noting that they have changed their archiver to match Sun's behavior. The search also turned up a hit that suggested that unarchivers would have problems with directory entries as you suggest.

I tried WinZip9.0SR1 and it had no problems extracting the files in the Jar that contained directory entries. I created a test directory structure that had and empty subfolder. Winzip ignored the subfolder when creating a zip archive and did not create the empty when extracting the archive. Creating the archive with Sun's Jar command did add the empty directory to the archive, and both Sun's Jar and Winzip created the empty directory when extracting.

Repeating this test with 7-Zip4.57 shows that 7-Zip creates the empty directories in the archive and duplicates Sun's Jar util's behavior.

[Norm Radder]

Tom,
Thanks for the info.