Just to be accurate, this not the launcher who uses "java.home",
rather luni natives invoke readClassPathFromPropertiesFile regardless
of the way VM is created and which launcher is used, if any.
I do not think this system is wrong *by design*. Reasonable thing to
do is to introduce more specialized property like "o.a.h.vm.home"
instead of using conventional "java.home", to reduce probability of
collision with user application specific utilization of properties.
Frankly speaking, I hardly imagine conscious application which needs
modification of "java.home". Accordingly to specification, "java.home"
defines Java installation directory, so changing it is at least weird.
--
Regards,
Alexey
2006/11/25, Gregory Shimansky <[EMAIL PROTECTED]>:
Gregory Shimansky wrote:
> Probably Geir meant internal native VM value for java.home property. Java
> program cannot change that. Even setting this property with -D command line
> switch won't give any effect on drlvm because it will be overridden on the
> initialization... and now that I've written it and tried to override
> java.home on command line, drlvm crashed :(
>
> The bug however seems to be in the launcher because it didn't set
> org.apache.harmony.boot.class.path to any value, so the property is NULL. I'm
> going to take a look (recompiling classlib with debug since it has no symbols
> by default).
A short investigation shows that launcher parses -Djava.home passed on
the command line. Later on while classlib is initialized the function
readClassPathFromPropertiesFile calls properties_load with file name
formed as ${java.home}/lib/boot/bootclasspath.properties. If this file
is not found and properties_load, then no value is assigned to
org.apache.harmony.boot.class.path.
I think this system is wrong. The launcher should not pay attention to
java.home passed on the command line. The location should be found from
the executable path probably. RI doesn't crash or fail its boot classes
when I specify bad -Djava.home on the command line.
--
Gregory
