Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-7145798

System.loadLibrary does not search current working directory

XMLWordPrintable

    • b01
    • x86
    • os_x
    • Verified

        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

              dcubed Daniel Daugherty
              webbuggrp Webbug Group
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: