harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [drlvm/classlib/jdktools] system property o.a.h.boot.class.path
Date Thu, 30 Nov 2006 02:15:42 GMT
2006/11/30, Geir Magnusson Jr. <geir@pobox.com>:
>
>
> 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?

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
>

Mime
View raw message