JDK-7145798 : System.loadLibrary does not search current working directory
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7,7u4
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86
  • Submitted: 2012-02-15
  • Updated: 2013-07-18
  • Resolved: 2012-02-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 Other
7u4Fixed 8Fixed hs23Fixed
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
/usr/libexec/java_home -v 1.7 --exec java -versionopenjdk version "1.7.0-u4-b228"
OpenJDK Runtime Environment (build 1.7.0-u4-b228-20120203)
OpenJDK 64-Bit Server VM (build 23.0-b12, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Darwin Mac-User.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

Version 10.6.8

A DESCRIPTION OF THE PROBLEM :
Overview of the JNI Design
http://java.sun.com/docs/books/jni/html/design.html
11.2.3 Locating Native Libraries

When the Java virtual machine starts up, it constructs a list of directories that will be used to locate native libraries for application classes. The contents of the list are dependent upon the host environment and the virtual machine implementation. For example, under the Win32 JDK or Java 2 SDK releases, the list of directories consists of the Windows system directories, the current working directory, and the entries in the PATH environment variable. Under the Solaris JDK or Java 2 SDK releases, the list of directories consists of the entries in the LD_LIBRARY_PATH environment variable.

The current Apple version of the jvm follows the Windows information in default searching the current working directory. The current openjdk version does not.

I was informed on the macosx-port list that because of security issues searching the current working directory is no longer considered a valid practice.

If this is not the case I think the search path should be restored to what has been normal for the platform.

If it is the case and a decision is made to intentionally change this behavior I think documentation should be provided to developers converting from the Apple JVM to the openjdk one listing exactly what known changes to jvm behavior have been made by the decision of the openjdk implementors.

REGRESSION.  Last worked in version 6u29

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
This works with the default search path and the Apple 1.6 jvm
 /usr/libexec/java_home -v 1.6 --exec java -cp .:halfpipe.jar TestMonitor
TestMonitor: terminated Eclipse /eclipse/Eclipse.app pid = 194

It does not work this way with the openjdk jvm
 /usr/libexec/java_home -v 1.7 --exec java -cp .:halfpipe.jar TestMonitor
Exception in thread "main" java.lang.UnsatisfiedLinkError: no hp in java.library.path

It does work openjdk with explicit -Djava.library.path

I have not tested with LD_LIBRARY_PATH

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The jvm behavior should be the same, whatever it is.
Or it should be documented, somewhere, as different.
ACTUAL -
The behavior is different with no indication anywhere that it is.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "main" java.lang.UnsatisfiedLinkError: no hp in java.library.path


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Not that brief. Could be provided.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Explicitly provide -Djava.library.path

Comments
EVALUATION http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/86ce3208eb18
26-03-2012

EVALUATION http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/86ce3208eb18
22-03-2012

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/86ce3208eb18
22-02-2012

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/86ce3208eb18
18-02-2012

SUGGESTED FIX See the attached "7145798-webrev-cr0.tgz" for the fix proposed in code review round 0.
17-02-2012

WORK AROUND Here is a work around: $ JAVA_LIBRARY_PATH="." java -showversion GetLibraryPath java version "1.7.0_04-ea" Java(TM) SE Runtime Environment (build 1.7.0_04-ea-b226) Java HotSpot(TM) 64-Bit Server VM (build 23.0-b10, mixed mode) java.library.path='.:/Users/dcubed/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java'
17-02-2012

EVALUATION Apple's version of Java includes "." in the java.library.path at the beginning. OpenJDK includes "." at the end of java.library.path on Windows. On Linux and Solaris, "." is not included at all. In the MacOS X port project, the relevant code was copied from Linux so "." is not present in java.library.path. This should be changed to make the OpenJDK7 version on MacOS X behave similar to the Apple version of Java6.
17-02-2012