harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pervov" <pmcfi...@gmail.com>
Subject Re: [drlvm/classlib/jdktools] system property o.a.h.boot.class.path
Date Mon, 04 Dec 2006 15:24:56 GMT
Hope, these changes didn't make their way to the SVN yet... See below.

On 11/30/06, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:

> 2006/11/30, Geir Magnusson Jr. <geir@pobox.com>:
> >
> >
> > Alexey Varlamov wrote:
> > > 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'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.


I believe, I can shed some light on the decision of making SetBCPElement
available to the public.
Magics are different from the rest of the jars in the way they belong to the
respective components, which provide these jars.
I don't see it as advantage for these jars to be available through any
public APIs for browsing - including system properties. That is why it was
suggested to Mikhail (Fursov; I believe there was a discussion on dev-list
on this topic) to implement it the way, it is now.


> > 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.


It is not exactly "regular use". Still, if you insist on keeping
SetBCPElement() private, merge the code from
bootstrap_add_components_classpath with
the BootstrapClassLoader initialization code.

<SNIP>

-- 
Pavel Pervov,
Intel Enterprise Solutions Software Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message