BUG in jdk1.5.0 : can't set sun.boot.library.path
Try this:
c:\jdk1.5.0\bin\java -Dsun.boot.library.path=anything TestVM
where TestVM.java is:
publicclass TestVM{
publicstaticvoid main(String args[]){
System.out.println("DONE");
}
}
Here's what I get as output:
Error occurred during initialization of VM
Unable to load native library: Can't find dependent libraries
And infact you don't even need an the TestVM code, because this gets same error:
c:\jdk1.5.0\bin\java -Dsun.boot.library.path=anything anything
Am I doing something wrong or is this a bug? I also tried setting sun.boot.library.path to include virtually every directory under jdk1.5.0, with no luck.
Can you reproduce? I've already submitted this as a BUG, so let me know if I'm right or wrong here.
You could write a small test app to dump the defaultthen try explicitly setting the same.
> You could write a small test app to dump the default
> then try explicitly setting the same.
Good idea. The default is "c:\jdk1.5.0\jre\bin" and if I execute:
c:\jdk1.5.0\bin\java -Dsun.boot.library.path=c:\jdk1.5.0\jre\bin -cp . TestVM
Then it works.
However, if I change it to anything but "c:\jdk1.5.0\jre\bin" I get the error. In other words if I make it "c:\jdk1.5.0\jre\bin;c:\ora9\bin" then I get the error. So I guess as a workaround I could dump all my libraries in c:\jdk1.5.0\jre\bin but that is not ideal.
> So I guess as a workaround I could dump all my
> libraries in c:\jdk1.5.0\jre\bin but that is not
> ideal.
What are you trying to do?
If you're wanting to cross-compile using an earlier Java version you should be using one of the forms of this java command option:
Xbootclasspath:bootclasspath
"Specify a semicolon-separated list of directories, JAR archives, and ZIP archives to search for boot class files. These are used in place of the boot class files included in the Java 2 SDK. Note: Applications that use this option for the purpose of overriding a class in rt.jar should not be deployed as doing so would contravene the Java 2 Runtime Environment binary code license."
If you're trying to extend Java with additional classes, use
Java's Extension Mechanism:
C:\Program Files\Java\jdk1.5.0\docs\guide\extensions\index.html
"Optional packages are packages of Java classes (and any associated native code) that application developers can use to extend the functionality of the core platform. The extension mechanism allows the Java virtual machine (VM) to use the classes of the optional extension in much the same way as the VM uses classes in the Java 2 Platform. The extension mechanism also provides a way for needed optional packages to be retrieved from specified URLs when they are not already installed in the JDK or JRE. "
>
> Am I doing something wrong or is this a bug?
Yes you are doing something wrong.
> I also
> tried setting sun.boot.library.path to include
> virtually every directory under jdk1.5.0, with no
> luck.
>
And why would you try that?
There is exactly one directory in the installed tree that that it should be set to. And if that is all you want then don't use the option in the first place.
> Can you reproduce?
Yes if I use it in 1.4.2 it blows up as well.
> I've already submitted this as a
> BUG, so let me know if I'm right or wrong here.
Unless you know exactly what you are doing with that option then leave it alone (do not use that option in the first place.)
That option basically tells it where to find everything it needs to run the VM (most of which is java.) If it can't find that stuff then it can't run.
Perhaps what you want to do is add something to it. If so first print out what it is in a java app by using...
System.out.println("n=" + System.getProperty("sun.boot.library.path"));
Then add a directory before that. (Which unless you know what you are doing is still going to be meaningless but at least then it will run.)
And as stated the bootpath options are a much better choice.
I tried to make my post as simple as possible so as not to confuse the less informed.
Look, I am in fact trying to use the Xbootclasspath flag because we are using some visibroker (corba) jar files which share some class/package names with the jdk, so I need to get the visibroker classes loaded first.
Now I am also trying to do this in my code:
System.loadLibrary("ocijdbc9");
Ok, now it turns out that if I use the Xbootclasspath flag then I get the UnsatisfiedLinkError, this is despite the fact that my code reports java.library.path as containing c:\ora9\bin (where ocijdbc9.dll is located).
So to make a long story short, I had seen that in previous jdk's you could use the sun.boot.library.path in conjunction with Xbootclasspath to tell java where to load libraries from.
However and here's the REALLY important part of my post.:
Adding the flag -Dsun.boot.library.path=c:\jdk1.5.0\jre\bin;c:\ora9\bin will cause the VM not to start up. In fact appending or prepending ANYTHING to the default sun.boot.library.path (in my case c:\jdk1.5.0\jre\bin) will cause the VM to fail on startup.
THIS IS NOT THE CASE FOR JDK1.4, or 1.3 !!!!!!!!!!!!!!!!!
Basically the sun.boot.library.path flag is now useless because adding anything to it causes the VM TO FAIL ON START UP. So basically I have to dump all my libraries into c:\jdk1.5.0\jre\bin.
Try it if you don't beleive me and let me know the results.
> I tried to make my post as simple as possible so as
> not to confuse the less informed.
Often it does help to state the exact problem rather than trying to make up another one.
> Look, I am in fact trying to use the Xbootclasspath
> flag because we are using some visibroker (corba) jar
> files which share some class/package names with the
> jdk, so I need to get the visibroker classes loaded
> first.
To be clear, it is not "loading them first" if the name is the same. It is loading them instead of the other ones.
>
> Now I am also trying to do this in my code:
> System.loadLibrary("ocijdbc9");
>
Presumably this or some other combination is preventing you from allowing the driver itself to do this itself.
Have you tried using System.load() and explicitly using the full path name?
> Ok, now it turns out that if I use the
> Xbootclasspath flag then I get the
> UnsatisfiedLinkError, this is despite the fact that
> my code reports java.library.path as containing
> g c:\ora9\bin (where ocijdbc9.dll is located).
>
Odd but then Oracle drivers tend to be odd.
> So to make a long story short, I had seen that in
> previous jdk's you could use the
> sun.boot.library.path in conjunction with
> Xbootclasspath to tell java where to load libraries
> from.
>
> However and here's the REALLY important part of my
> post.:
> Adding the flag
> -Dsun.boot.library.path=c:\jdk1.5.0\jre\bin;c:\ora9\bi
> n will cause the VM not to start up. In fact
> appending or prepending ANYTHING to the default
> t sun.boot.library.path (in my case
> c:\jdk1.5.0\jre\bin) will cause the VM to fail on
> startup.
>
> THIS IS NOT THE CASE FOR JDK1.4, or 1.3
> !!!!!!!!!!!!!!!!!
And now that the actual problem is explained I can see where that is a problem.
> Basically the sun.boot.library.path flag is now
> useless because adding anything to it causes the VM
> TO FAIL ON START UP. So basically I have to dump all
> my libraries into c:\jdk1.5.0\jre\bin.
Technically I am not sure that "useless" is quite correct. As far as I can determine the only point for that option is to specify where the internal VM stuff is. Normally I can't see that there would need to be more than one location. The only expected legitimate use would be when something needs to proxy the entire VM. And that would still only need one location. So in terms of the intent of the specific option it doesn't need more than one location.
>
> Try it if you don't beleive me and let me know the
> results.
I don't expect that I will actually install 1.5 until sometime next year.I don't like being on the bleeding edge and my current work requires a previous version. But I don't doubt that it fails.
If System.load() doesn't help then I see the following possibilities
- Verify the bootpath option that you tested with previously is correct.
- Get the source for 1.5. Find out why this no longer works. Replace the class that is different (you are already replacing VM classes so this is not different.)
- Determine why the oracle driver isn't working. I suspect something is 'wrong' with the visibroker replacement classes, probably because you are using a version was developed with 1.3 java rather than 1.5. And the driver expects something in 1.5 (and which was in 1.4.) You might be able to get around this by using a custom class loader to load the driver. You will still need the VM class though.
Another suggestion...1.5 loads a binary image of the core files.There is a command line switch that prevents that. Try turning it off and see if that allows you to use the option again.
>>Often it does help to state the exact problem rather than trying to make up another one.
Look the point of the post is REALLY that you can't add anything to the default sun.boot.library.path, the longer post I gave explains WHY I want to do that. But the WHY is irrelavent.
My point is this:
FIrst you can't change sun.boot.library.path even if you try to add stuff to it and leave the original value there as well
Secondly but less important, it seems that if you use Xbootclasspath and if the class loaded through Xbootclasspath tries to load a library through System.loadLibrary, that the normal paths are ignored, and java will fail to load the library. So, and here's how I discovered the problem, if you try to use sun.boot.library.path to specify a path for libraries loaded through Xbootclasspath, you cannot alter, append to or prefix the default sun.boot.library.path or you get an error and the VM will NOT START. This is not the case for PREVIOUS JDKS!!!!!!! So thats why I think its a BUG
> >>Often it does help to state the exact problem
> rather than trying to make up another one.
> Look the point of the post is REALLY that you
> can't add anything to the default
> sun.boot.library.path, the longer post I gave
> explains WHY I want to do that. But the WHY is
> irrelavent.
>
> My point is this:
> FIrst you can't change sun.boot.library.path even if
> you try to add stuff to it and leave the original
> value there as well
Ok. But I pointed out that as this is an internal feature of the VM. How it works between versions or even if it works at all is entirely up to Sun. And "adding" stuff to it seems inconsistent to me anyways given the likely purpose.
>
> Secondly but less important, it seems that if you use
> Xbootclasspath and if the class loaded through
> Xbootclasspath tries to load a library through
> System.loadLibrary, that the normal paths are
> ignored, and java will fail to load the library. So,
> and here's how I discovered the problem, if you try
> to use sun.boot.library.path to specify a path for
> libraries loaded through Xbootclasspath, you cannot
> alter, append to or prefix the default
> sun.boot.library.path or you get an error and the VM
> will NOT START. This is not the case for PREVIOUS
> JDKS!!!!!!! So thats why I think its a BUG
And in previous versions System.getenv() worked, didn't work (threw an exception) and now it works again in 1.5.
And that is a documented method.
Feel free to write this up as a bug if you wish. Sun might even fix it (although that might be more likely if you looked into the source code and explained to them why it worked before and doesn't work now.)
If it was me though I wouldn't expect it to be fixed soon. And the bug might be rejected because as I pointed out it is an internal feature. Or because now it works as Sun intended in the first place and the behavior you saw before was the bug.
And finally relying on this for ongoing work is very dubious.There are already documented features for replacing, adding, modifying the VM. This is an internal feature. What are you going to do if Sun removes it entirely?
This has now been accepted as an In Progress Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6214495
> This has now been accepted as an In Progress Bug:> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6214495Oddly enough that link brings up the bug but the searching for the bug id does not.
> Oddly enough that link brings up the bug but the> searching for the bug id does not.Yes I noticed the same. Maybe cause its so new.
