On 24 June 2006 at 14:44, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > On Saturday 24 June 2006 09:19 Mark Hindess wrote: > > On 24 June 2006 at 1:43, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > > > On Saturday 24 June 2006 00:04 Mark Hindess wrote: > > > > Indeed. See my comment in the JIRA HARMONY-651. I would have used > > > > the version from classlib, but there is an outstanding issue with > > > > serializer.jar - which drlvm current adds to jre/lib/boot but classlib > > > > does not. > > > > > > I am probably missing something, what is the reason not to include > > > serializer.jar to the classlib bootclasspath by default? > > > > Sorry, what I am trying to understand is... > > > > Classlib doesn't include it because it doesn't appear to require > > it (specifically all tests pass without it). (Perhaps this is a > > limitation of the classlib tests - there aren't really any tests for > > the xml APIs.) Why does drlvm require it? > > > > If drlvm requires it then there is a good chance that classlib > > also requires it and it should be added to classlib, but I want to > > understand why it is necessary. Perhaps I'll have a closer look at > > drlvm and see how it is using it, but I figured that someone on the > > list would already know. > > > > Basically I'm trying to figure out if classlib has a problem we are > > not seeing (yet) because serializer.jar is missing. > > Sorry if it wasn't clear, I never meant that serializer.jar is > actually needed to run classlib + drlvm. Yesterday when I tried > bootclasspath.properties from > > classlib I didn't have to add serializer.jar to it to make run simple > programs. I don't know why drlvm has it in its bootclasspath.properties, > probably just because it exists. It doesn't seem to be needed yet.
Ok. So if I remove it and use the bootclasspath.properties file from classlib it should work - with respect to xerces/xalan update and the loss of serializer.jar. But that leaves . . . > 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! ... The only place you should find stubs of classes should be in luni-kernel-stubs.jar and security-kernel-stubs.jar (they used to be in one file but now they are split.) However, due to an oversight in the patternsets, and the fact that the classes build to a common directory, they also get included in luni.jar and security.jar. For the IBM VME, the stubs are replaced by the jars listed injre/bin/default/clearvm.properties - i.e. luni-kernel.jar and security-kernel.jar. I should mention that String is intended to be in luni.jar. It was agreed some time back to move String out of the set of kernel classes in to luni. (Although it was always intended that a VM implementation could override the String if it wished to do so.) 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]
