On 6/24/06, 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.propertiesfrom 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.
It's not clear why this file has been added to the bootclasspath. 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.
Indeed, the classlib sources contain the stabs for the kernel classes. They can be used by VM developers as start point. These classes are VM-specific and have to be a part of the VM implementation (kernel.jar file). Perhaps it makes sense to exclude these classes from the luni.jar to avoid similar surprises. What does the Harmony community think about this? Thanks, Vladimir. --
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]
