harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@apache.org>
Subject Re: ECJ and Harmony
Date Wed, 23 May 2007 15:37:09 GMT
Olivier Thomann wrote:
> news <news@sea.gmane.org> 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.


View raw message