[classlib] Launcher fails to find properties location when bad -Djava.home is specified on the command line

[Gregory Shimansky <gs...@gmail.com>]

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

Re: [classlib] Launcher fails to find properties location when bad -Djava.home is specified on the command line

[Alexey Varlamov <al...@gmail.com>]

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 <gs...@gmail.com>:
> 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
>
>