Mark Hindess wrote: > 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.
Right - that wasn't the issue though. > 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. Great. geir > > 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] > > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
