2006/11/30, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
Alexey Varlamov wrote: > 2006/11/30, Geir Magnusson Jr. <[EMAIL PROTECTED]>: >> (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?
Composing BCP from prefixes and postfixes, and keeping whole runtime BCP string as a property. They just add jars directly to a vector of searching elements of BootstrapClassLoader, and this is no good from my POV.
> 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.
OK. Though I have to touch that code anyway, to update properties usage.
> >> >> 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.
Understood, no objections.
> >> >> 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
