On 25 June 2006 at 6:42, "Magnusson, Geir" <[EMAIL PROTECTED]> wrote: > > Mark Hindess wrote: > > > > 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. > > > >=20 > > > > 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.
The stubs aren't mentioned in the bootclasspath.properties so they aren't a problem. The problem I was alluding to is that DRLVM predates the move of String from the kernel to luni so if DRLVM defines String then it's version should be loaded first. We can't get rid of luni.jar. ;-) The problem was worse before because there were (unintentionally) some stub classes in the luni and security jars. This was what I fixed in r417017. Regards, Mark. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
