JDK-4414763 : System.load() fails to load library from jar file
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2001-02-13
  • Updated: 2001-02-23
  • Resolved: 2001-02-23
Description

Name: ssT124754			Date: 02/13/2001


java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

It is not possible to load a native library if it is contained inside a jar
file.

The resource specification "jar:file:file.jar!some.dll" given to the System.load
() is ignored, the load attempt results in an java.lang.UnsatisfiedLinkError.

The details of the message state that an "...absolute path was not found..."

Since this format ("jar:file:file.jar!somefile") works when loading resources
it can be considered an absolute path, at least into the jar file. System.load
() should not reject this resource specification format
(Review ID: 116877) 
======================================================================
Comments
WORK AROUND Name: ssT124754 Date: 02/13/2001 Tell me if there is one... ======================================================================
11-06-2004
PUBLIC COMMENTS Including native library in a JAR file contradicts with very basic Java philosophy. A JAR file must be used for machine independent bits only, since JAR was designed mainly to facilitate the packaging of Java applets or applications into a single archive. When the components of an applet or application (.class files, images and sounds) are combined into a single archive, they may be downloaded by a Java agent (like a browser) in a single HTTP transaction, rather than requiring a new connection for each piece. This dramatically improves download times. JAR also compresses files and so further improves download time. In addition, it allows individual entries in a file to be signed by the applet author so that their origin can be authenticated.
10-06-2004
EVALUATION Including native library in a JAR file contradicts with very basic Java philosophy. A JAR file must be used for machine independent bits only, since JAR was designed mainly to facilitate the packaging of Java applets or applications into a single archive. When the components of an applet or application (.class files, images and sounds) are combined into a single archive, they may be downloaded by a Java agent (like a browser) in a single HTTP transaction, rather than requiring a new connection for each piece. This dramatically improves download times. JAR also compresses files and so further improves download time. In addition, it allows individual entries in a file to be signed by the applet author so that their origin can be authenticated. Internally VM has a few properties for storing path information. Native libraries paths are stored in "Java.library.path" property and path information for platform independent components like class files or JARs is stored in "Java.class.path" property. The path information stored in this two properties is used and processed ABSOLUTELY differently, there is no way to intermingle them. Besides if we do so, we immediately violate VM backward compatibility, which can be a real issue. Just think about applications embedding VM - we have no idea which native libraries can be found in CLASSPATH directories. david.wallman@Eng 2001-02-23
23-02-2001