> -----Original Message----- > From: Tim Ellison [mailto:[EMAIL PROTECTED] > > 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. > Small typo - I believe it's 2.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]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
