Gregory Shimansky 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?
We upgraded Xerces version a while ago to 3.8.0. That version no longer contains a 'serializer.jar' -- that's why it no longer appears in the bootclasspath. Regards, Tim >> As I suggested in an earlier message (subject Re: [drlvm] Doing the >> minimum to support Java 5 classfiles) I think drlvm's deploy tree >> shouldn't contain any classlib files but should produce a deploy tree >> that a top-level build can combine with a classlib tree to produce a >> fully working deploy tree. Much like we do manually when we combine the >> IBM VME and classlib. > > Agreed. > >> That is, we should do more to reduce the coupling between drlvm and >> classlib. At the moment, drlvm is trying to understand classlib - i.e. >> knowing what to copy across but it is not going to be maintainable. >> (And arguably it is already failing because it is not copying the jre/ >> lib/ext/bcprov.jar that classlib uses - instead drlvm puts an older >> version in jre/lib/boot. This is just confusing we should stop trying >> to do it in drlvm and delegate this task to the top-level build.) > > Yes, as I wrote in another mail in this thread, I think classlib should > contain all of the information about itself in its files. VM should just > follow the agreement, be it bootclasspath.properties or some other file which > describes classlib contents to figure out which files classlib has and what > they are meant to be in classlib. > >>> Gregory? >> I'd like to know what Gregory thinks about this too. > > See above. Now what I found out trying to use bootclasspath.properties from > classlib... > > I think that the file from classlib is mostly ok. The DRLVM file parser which > I thought to blame at first happened to be ok. It does add lots of garbage to > the bootclasspath addring everything after '=' symbol to the property > assuming it is a file name, so names like "luni-src.jar" and "/" with full > path prepended to them appear in the bootclasspath property, but at least it > is not causing any crashes. > > The problems which I had was that java/lang/VMClassRegistry could not be > found. The reason was simple, classlib doesn't mention kernel.jar in > bootclasspath.properties. Addind kernel.jar to the file fixes the problem... > sometimes. > > There is a weird fact that if kernel.jar is added before luni.jar everything > just works. If its bootclasspath index is after luni.jar, VM goes into some > infinite recursion in java code which in JIT mode causes just infinite > execution, in interpreter it crashes on some synchronization locks limit. > > I didn't really analyze the cause for this strange behavior yet, maybe my > finding is not really correct. I'll try to investigate this strange situation > tomorrow. > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
