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(). I'll fix this while integrating properties refactoing submission (HARMONY-1925), please shout if there are objections.
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?
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
