harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: svn commit: r416738 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath.properties
Date Sat, 24 Jun 2006 21:33:11 GMT
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 (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message