2006/11/30, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
Alexey Varlamov wrote: > 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'm confused. We do need to have the string, at least able to be created on demand.
Indeed - and I see no reason why treat magics differently.
Do you believe that adding jars directly is no good?
I prefer to have the consistent way. IMHO BootstrapClassLoader::SetBCPElement() should not be public, it is just a part of BootstrapClassLoader initialization and not intended for regular usage.
> >> >> > 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. Right - so just update the properties usage, and then suggest whatever. Don't mix up the activities please. It makes analyzing the specific changes made to the algorithm/approach really hard if it's mixed with the switch to new properties system. geir
