Olivier Thomann wrote:
news <[EMAIL PROTECTED]> wrote on 2007-05-23 10:34:43:
I reported the bug on version 3.2.2 because that is the version where
I've reproduced it. I think unless someone else thinks otherwise 3.3 is
good enough for us. Thanks a lot for a quick response!
Ok. Once the patch will be ready, it should not be difficult to apply it
to the 3.2 maintenance stream anyway.
This being said, the property sun.boot.class.path is also defined for
harmony and it does contain the kernel.jar that contains java.lang.Object.
As far as I can tell, the property org.apache.harmony.boot.class.path
doesn't contain a jar that has java.lang.Object in it.
So I should go for the first property.
Ah I was mistaken when I wrote that org.apache.harmony.boot.class.path
is the right property to be used. This property is created by classlib
initialization code and actually specifies all JAR files which classlib
has (kernel classes are VM specific). DRLVM adds kernel.jar to the
property and creates vm.boot.class.path and sun.boot.class.path, the
latter for compatibility with Sun.
The problem here comes from IBM VME because it provides its full boot
class path including kernel classes in
org.apache.harmony.boot.class.path too, probably redefining its value
upon initialization. So there are 2 ways to fix the bug.
1. Make DRLVM redefine org.apache.harmony.boot.class.path too and add
kernel.jar to its beginning. I think this won't break any functionality
and should be quite easy to implement.
2. Make IBM VME provide vm.boot.class.path or sun.boot.class.path with
the same value as org.apache.harmony.boot.class.path. This will require
a change of IBM VME binary and isn't very easy to do.
--
Gregory
