2

Was trying to follow http://java.sun.com/docs/books/tutorial/uiswing/components/icon.html when came across error. Seems that getResource returns null when accessing the page locally (i.e., when URL is, say, "C:\projects\html\test.html") in IE6. Class and resource are in same Jar file.

Anybody know the reasons and a work-around (if one exists)?

Encountered in Win XP/IE 6/JRE 1.6.0_11, but not in Win XP/IE 7/1.6.0-b105.

In the environment where it's working, the class loader is:

sun.plugin.security.PluginClassLoader

In the environment where it's broken, it's:

sun.plugin2.applet.Applet2ClassLoader
Andrew Thompson
  • 168,117
  • 40
  • 217
  • 433
Chry Cheng
  • 3,378
  • 5
  • 47
  • 79

5 Answers5

2

As Nick mentioned, Java 6 update 11 changed the security settings for applets running on the filesystem. By using getResource() you are loading from a URL and may have accidentally bumped up against the new restrictions which shouldn't really apply to you.

Try getResourceAsStream() instead, like this:

InputStream in = getClass().getResourceAsStream("image.jpg");
Image image = ImageIO.read(in);
ImageIcon icon = new ImageIcon(image);

I haven't actually tested this but I don't generally run applets from the filesystem :)

Spyder
  • 1,882
  • 13
  • 23
1

Sounds like the difference there is that you are using the "next-generation" plugin technology in 1.6u10. You can disable it and use the older plugin technology by changing the appropriate option under the Advanced tab in the Java Control Panel. That may at the very least isolate your problem to a particular version.

Joel Carranza
  • 967
  • 2
  • 12
  • 19
1

Did you check for messages in the Java Console?

As far as I remember Internet Explorer 6 has stricter security rules than older IE5 or Netscape/Mozilla. While Netscape allows applets opened from the local drive to access resources on that drive, IE does not. You might see some security exception in the console in this case.

To workaround set up a local webserver, e.g Tomcat and access the html file containing the applet through it, e.g. http://127.0.0.1:8080/some/applet.html. Then the applet is not from your harddist any more and is able to access any resource served by the server http://127.0.0.1:8080/.

Peter Kofler
  • 9,252
  • 8
  • 51
  • 79
0

The security settings running locally is very restrictive, see security report (similar question asked here).

As suggested in another answer, run it in a web-server (eg tomcat) and most of your problems should be gone.

Community
  • 1
  • 1
Pool
  • 11,999
  • 14
  • 68
  • 78
-1

Just a guess: Perhaps applet security limitations are applying here? In general, unless the applet is not signed, it is not allowed to access local resources. I'm not sure how this works if the applet is opened from a locally stored page, but it well may be the root cause.

Signing the applet an accepting the certificate in browser may solve the problem.

david a.
  • 5,283
  • 22
  • 24