> -----Original Message----- > From: Mark Hindess [mailto:[EMAIL PROTECTED] > Sent: Sunday, June 25, 2006 9:27 AM > To: [email protected] > Subject: Re: svn commit: r416738 - > /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/boo > tclasspath.properties > > > On 24 June 2006 at 22:38, Tim Ellison <[EMAIL PROTECTED]> wrote: > > Mark Hindess wrote: > > > On 24 June 2006 at 14:44, Gregory Shimansky > <[EMAIL PROTECTED]> wrote: > > >> Btw I've figured why kernel.jar has to be added to > > >> bootclasspath.properties before luni.jar. They have many > classes with > > >> the same name but different code (Class, ClassLoader, > Thread, System, > > >> String to mention a few). So if luni.jar goes first in > bootclasspath, > > >> then all of those kernel classes implementations are taken from > > >> classlib which isn't very good because they should be > taken from VM's > > >> kernel.jar. So there is no surprise that it doesn't work. > > > > > > Oops... I can't believe we didn't spot this before! ... > > > > That's a regression :-( We used to specifically exclude the kernel > > patternsets from each JAR packaging step. I agree that it should be > > restored. > > Yes, it's definitely a regression. Probably at least partly my fault, > so I've fixed it in r417017. > > Gregory, this should almost fix the ordering issue except for String > which has moved out of the kernel classes in to luni. But as Tim says > the real solution is to load the VM's versions of kernel classes first > the same way the IBM VME does it.
Isn't it better to not have the stubs around at all? Gets rid of one element of uncertainty - load order. geir --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
