I've been using the loadImage (uses Imageio.read(getClass().getResource()) class from the wiki in my java projects lately. I'd been loading images in a jar from an app inside a jar with no problems.

Now I'm working with an applet inside a jar. The jar contains the applet, some misc class files, an image file (.gif), and another jar. The manifest only has ClassPath defined for the jar in the jar. The applet loads and runs fine except the images are smeared.

It makes me think that the getClass.getResource isn't recognizing the image is in a jar when in fact it is.

The file structure in the jar looks like this:

Manifest.mfjs.jarapplet.classmisc.classmisc.classimage.gif

I hate to go thru the trouble of opening a url connection to a jar file if I don't have too? I shouldn't have to, should I?

It should work the same for Applets. Describe "smeared". If it wasn't working you should get something like ResourceNotFound or another error loading the image. It sounds like the problem is something else.

I tried putting the image in a subdirectory in the jar and in the sub jar (which the manifest classpath points to)

Sub-jar? You can't have a jar inside a jar be part of the classpath.. the manifest is meant to point to other jars in the same place as the first. And for applet I think you still need an attribute in your Applet tag to download the additional jars.

The example image is interesting.. Are you not seeing any exceptions? You aren't accidently covering one up with an empty catch block or something are you?The fact that you can see generally correct colours in the bad image tells be that it must be finding the image data some how... but maybe the images are being used before they are loaded, or your images are being corrupted in the jar... maybe even you have classpath issues and the images that work are coming from the current directory instead of the jar somehow? Maybe you are running in different JVMs - like the MS JVM for applets, but the Sun VM for Applications?

The URLs in the Class-Path header are given relative to the URL of the JAR file of the applet or application.

So I removed the sub jar and the gif. The applet should have been referencing the gif in the applets home directory and the jar. Everything was fine, the output of the applet was the same for both the jar version and the non-jar version.

Then I placed the gif in a sub directory in the jar (and recompiled) and the smear returns. Weird.

No exceptions are blocked out; my code is the ImageLoader straight from the wiki. Hmm...

The applet is running jre 1.4.2... jdk is 1.4.0 (!)

Damn, I thought I was compiling with jdk 1.4.2 these past months; could that cause a problem?

I downloaded 1.4.2 and recompiled, no difference. The only thing I've been able to find in the docs is this bit about urlclassloader:

Quote

This class loader is used to load classes and resources from a search path of URLs referring to both JAR files and directories. Any URL that ends with a '/' is assumed to refer to a directory. Otherwise, the URL is assumed to refer to a JAR file which will be opened as needed.

So since I'm using JApplet, maybe its giving me a urlclassloader instead of a regular classloader (from getClass.getResource)? If its assuming the data for the gif is in a jar could that explain the misplaced colors?

I'll try to put something together this evening and post it. Its pretty simple; a JApplet using getClass().getResource() to load an image 1. from the home directory or 2. from a jar.

Rereading the first post I see you're attempting to do something strange as well; you can't access jars inside jars, if you see what I mean - the only resource you have available is the embedded jar. You'll have to open the jar and read data out of it in a separate step.

Quote:The URLs in the Class-Path header are given relative to the URL of the JAR file of the applet or application.

So I removed the sub jar and the gif. The applet should have been referencing the gif in the applets home directory and the jar. Everything was fine, the output of the applet was the same for both the jar version and the non-jar version.

Yep, fixed that problem too.

This is the problem which the zip illustrates:

Quote

Its pretty simple; a JApplet using getClass().getResource() to load an image 1. from the home directory or 2. from a jar.

It is also influenced by the browser cache. I've done the following:1. Compile and jar with the working workaround (loading data before sending it to ImageIO)2. Open applet in Internet explorer. The image shows correctly.3. Change source code to use the bugged imageloader. Compile and jar it.4. Reload internet explorer using ctrl+reload. The image shows correcly.5. Close all instances of internet exploerer6. Opening the same applet again. The image is bugged.

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