On Sunday 25 June 2006 17:26 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. > > > > > > 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.
Sure I've created a patch to properties parser which adds kernel.jar unconditionally to the beginning of bootclasspath, and filters out everything which isn't beginning with bootclasspath.[0-9] so no *.source and other properties appear in the property. -- Gregory Shimansky, Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
