Security checks may be overly conservative when resources from a jar are being loaded. This occurs when the runtime cannot resolve the origin server IP address during a resource load from a jar file. 

The following has been lifted from bugid 4320895:

The bug has been observed in the following scenario:

1. Running an application in a sandbox and with proper proxy
   settings on the SWAN (using Jump).

2. The URLClassLoader is used to download jar files from an
   external website, e.g., www.swingteam.com

3. The URLClassLoader correctly downloads the jar file.

4. The application looks up an resource in the downloaded
   jar file, e.g., MainClass.class.getResource("arrow.gif").
 
   This should return a URL, such as: 

      jar:http://www.swingteam.com/apps/draw.jar!arrow.gif

5. The URLClassLoader.getResource will eventually call into
   SocketPermission.impliesIgnoreMask to check if:

   (java.net.SocketPermission www.swingteam.com connect,accept,resolve)

   implies:

   (java.net.SocketPermission www.swingteam.com:80 connect,resolve)  

   This should obviously be true. (We just downloaded a jar file from
   www.swingteam.com using the httpProxies).

6. The above check returns false, because the www.swingteam.com is outside 
   the firewall, so the name cannot be resolved. SocketPermission.getIP throws 
   an UnknownHostException