harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm/classlib/jdktools] system property o.a.h.boot.class.path
Date Thu, 30 Nov 2006 01:59:27 GMT


Alexey Varlamov wrote:
> 2006/11/30, Geir Magnusson Jr. <geir@pobox.com>:
>> (How's that for a category in the subject line?)
>>
>> I'm working on jdktools, and was getting javac going.  We have a small
>> issue.  Currently, the wrapper code grabs the boot class path via the
>> system property
>>
>>     org.apache.harmony.boot.class.path
>>
>> This is initially set by luni, which collects all the entries in
>> bootclasspath.properties and adds them to the path.
>>
>> Now, the one thing that it doesn't do is include the kernel.jar, as
>> that's a degree of freedom for the vm which provides that jar.
>>
>> Now, in DRLVM, we take the o.a.h.b.c.p and prefix the kernel.jar, prefix
>> and postfix -Xbootclasspath/? for a complete runtime bootclasspath, and
>> call it
>>
>>     vm.boot.class.path
> 
> Things are changing :) Since recent H-2008 commit, magics support jars
> are going to bypass this machinery and slip into boot loader directly
> via SetBCPElement().

Bypass what machinery?

> I'll fix this while integrating properties refactoing submission
> (HARMONY-1925), please shout if there are objections.

Fix what?

I'd very much prefer that things happened in clear order - don't 
integrate Harmony-1925 and do other things at the same time.  Lets get 
it in first, and then start using it.

> 
>>
>> I had to modify the javac wrapper to use this rather than o.a.h.b.c.p.
>>
>> We need to change something - either we can suggest that VMs modify the
>> value of o.a.h.b.c.p, or create a new one -  formally declare something
>> like
>>
>>    o.a.h.vm.boot.class.path
>>
>> as a standard property for this purpose.
>>
>> I prefer the latter - it keeps it cleaner, and makes it easy to figure
>> out what the VM is glomming on.
> 
> For me, lesser properties diversity is better. Do we have some
> sensible use for o.a.h.b.c.p alone?

No, but it keeps it clean and clear who's modifying what.  o.a.h.b.c.p 
represents a classpath created from static data.  While it would be more 
efficient to replace it, for now, I think I'd be happier if we kept 
things separate for clarity.

> 
>>
>> If we agree, I'll do the switch in DRLVM and javac.  There should be no
>> changes required elsewhere.
> 
> Please hold on DRLVM mods, until I finish with H-1925 (hopefuly today).
> 
> -- 
> Alexey

Mime
View raw message