JDK-6214495 : Any attempt to set sun.boot.library.path causes VM to fail
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-01-06
  • Updated: 2010-08-19
  • Resolved: 2005-09-29
Related Reports
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
CLASSPATH is not set (empty)
PATH is not set (empty)
JAVA_HOME is not set
LD_LIBRARY_PATH is not set
LIB_PATH is not set


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
set CLASSPATH=
set PATH=
set LD_LIBRARYPATH=
set LIB_PATH=
set JAVA_HOME=
c:\jdk1.5.0\bin\java -Dsun.boot.library.path=anything TestVM


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
should run the TestVM.class main() method:

public class TestVM {
	public static void main(String args[]) {
		System.out.println("DONE");
	}
}


ACTUAL -
Error occurred during initialization of VM
Unable to load native library: Can't find dependent libraries

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Error occurred during initialization of VM
Unable to load native library: Can't find dependent libraries

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class TestVM {
	public static void main(String args[]) {
		System.out.println("DONE");
	}
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Well obviously don't  use -Dsun.boot.library.path option when starting VM.

However, I if you need to use -Xbootclasspath and load system libraries with System.loadLibrary then in previous jdk's the solution was to use -Dsun.boot.library.path. I have not found a workaround for this.
###@###.### 2005-1-06 00:17:48 GMT

Comments
SUGGESTED FIX The problem is causes by parsing which only accepts a single directory pathname rather than a delimiter separated list of such paths. This needs to be fixed anyplace get_dll_dir() is called. This includes os.cpp, classLoader.cpp and thread.cpp (and perhaps others).
29-09-2005

EVALUATION After further discussions, I'm moving this back to "Will Not Fix". That seems to be the preference of engineers here with significant history. See Fuggested fix as to how this *could* be fixed.
29-09-2005

EVALUATION The right answer here is probably "Will Not Fix". The sun.boot.library.path property is an artifact of our implementation. It is not something that users should be setting. ###@###.### 2005-1-12 16:36:59 GMT ###@###.### 2005-1-12 16:54:41 GMT In investigating the fix for 6271065, I uncovered the reasons for the change in behavior with Java 5.0. The JVM start-up code was altered to use this property to locate start-up resources rather than a private variable. However, the fact that this property may be a path of directories, rather than a single directory was overlooked. (I tried to locate the exact change which caused this, but the SCCS histories are rather convoluted - not worth the effort.) Also, this fix wasn't neede4d for 6271065 after all, but as long as I've got it, I shouldn't just drop it - hence, I'm reopening the bug. Note that fixing this doesn't alter the statement that external parties should not be using/depending on this for their products. It is a useful debugging tool but should not be considered as more than that. At all points of reference, the code should be modified to handle a path rather than just a single directory.
12-01-2005