You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Geir Magnusson Jr." <ge...@pobox.com> on 2006/11/30 00:35:53 UTC
[drlvm/classlib/jdktools] system property o.a.h.boot.class.path
(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
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.
If we agree, I'll do the switch in DRLVM and javac. There should be no
changes required elsewhere.
geir
Re: [drlvm/classlib/jdktools] system property o.a.h.boot.class.path
Posted by Alexey Varlamov <al...@gmail.com>.
2006/11/30, Geir Magnusson Jr. <ge...@pobox.com>:
>
>
> Alexey Varlamov wrote:
> > 2006/11/30, Geir Magnusson Jr. <ge...@pobox.com>:
> >>
> >>
> >> Alexey Varlamov wrote:
> >> > 2006/11/30, Geir Magnusson Jr. <ge...@pobox.com>:
> >> >>
> >> >>
> >> >> Alexey Varlamov wrote:
> >> >> > 2006/11/30, Geir Magnusson Jr. <ge...@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.
> >
> >> 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.
>
> OH! So you're saying that you don't like the direct injection into the
> vector, but rather would normalize it into the way it's happening now in
> BootstrapClassloader?
>
> if so, I agree 100% - sorry about the confusion
Nice!
>
> geir
>
Re: [drlvm/classlib/jdktools] system property o.a.h.boot.class.path
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Alexey Varlamov wrote:
> 2006/11/30, Geir Magnusson Jr. <ge...@pobox.com>:
>>
>>
>> Alexey Varlamov wrote:
>> > 2006/11/30, Geir Magnusson Jr. <ge...@pobox.com>:
>> >>
>> >>
>> >> Alexey Varlamov wrote:
>> >> > 2006/11/30, Geir Magnusson Jr. <ge...@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.
>
>> 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.
OH! So you're saying that you don't like the direct injection into the
vector, but rather would normalize it into the way it's happening now in
BootstrapClassloader?
if so, I agree 100% - sorry about the confusion
geir
Re: [drlvm/classlib/jdktools] system property o.a.h.boot.class.path
Posted by Pavel Pervov <pm...@gmail.com>.
>
> [snip]
> > 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.
> They are no way different than kernel.jar, which belongs to vmcore.
> Just a matter of modular packaging, nothing more.
They are different from kernel.jar in the way kernel.jar contains part
of API specification classes implemented in it and component jars are
intended for internal VM use only and does not contain any public classes.
That is the difference. That is why I do not think these jars should be
available through public APIs too.
> I don't see it as advantage for these jars to be available through any
> > public APIs for browsing - including system properties.
> I can see some advantages - e.g. being clear and predictable.
IMHO, what is currently implemented *is* clear and predictable. :) The only
issue I can see in current implementation is code localization and
incapsulation.
> 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.
> Usually they call it a "hack", when an public API is there but not
> meant for regular use ;) So I will do as you suggest, move it to
> BootstrapClassLoader::Initialize().
Hmm... Probably, you are right - it's a hack. :) So, change it, thanks.
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
Re: [drlvm/classlib/jdktools] system property o.a.h.boot.class.path
Posted by Alexey Varlamov <al...@gmail.com>.
2006/12/4, Pavel Pervov <pm...@gmail.com>:
> Hope, these changes didn't make their way to the SVN yet... See below.
Pavel, thank you for explicit argumentation. Answers are inlined below, too.
[snip]
> 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.
They are no way different than kernel.jar, which belongs to vmcore.
Just a matter of modular packaging, nothing more.
> I don't see it as advantage for these jars to be available through any
> public APIs for browsing - including system properties.
I can see some advantages - e.g. being clear and predictable. Similar
arguments you can find in the very beginning of this thread, btw. So
if you see no disadvantages either, we better change this.
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.
Usually they call it a "hack", when an public API is there but not
meant for regular use ;) So I will do as you suggest, move it to
BootstrapClassLoader::Initialize().
--
Alexey
Re: [drlvm/classlib/jdktools] system property o.a.h.boot.class.path
Posted by Pavel Pervov <pm...@gmail.com>.
Hope, these changes didn't make their way to the SVN yet... See below.
On 11/30/06, Alexey Varlamov <al...@gmail.com> wrote:
> 2006/11/30, Geir Magnusson Jr. <ge...@pobox.com>:
> >
> >
> > Alexey Varlamov wrote:
> > > 2006/11/30, Geir Magnusson Jr. <ge...@pobox.com>:
> > >>
> > >>
> > >> Alexey Varlamov wrote:
> > >> > 2006/11/30, Geir Magnusson Jr. <ge...@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
Re: [drlvm/classlib/jdktools] system property o.a.h.boot.class.path
Posted by Alexey Varlamov <al...@gmail.com>.
2006/11/30, Geir Magnusson Jr. <ge...@pobox.com>:
>
>
> Alexey Varlamov wrote:
> > 2006/11/30, Geir Magnusson Jr. <ge...@pobox.com>:
> >>
> >>
> >> Alexey Varlamov wrote:
> >> > 2006/11/30, Geir Magnusson Jr. <ge...@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.
> 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
>
Re: [drlvm/classlib/jdktools] system property o.a.h.boot.class.path
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Alexey Varlamov wrote:
> 2006/11/30, Geir Magnusson Jr. <ge...@pobox.com>:
>>
>>
>> Alexey Varlamov wrote:
>> > 2006/11/30, Geir Magnusson Jr. <ge...@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.
Do you believe that adding jars directly is no good?
>
>>
>> > 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
Re: [drlvm/classlib/jdktools] system property o.a.h.boot.class.path
Posted by Alexey Varlamov <al...@gmail.com>.
2006/11/30, Geir Magnusson Jr. <ge...@pobox.com>:
>
>
> Alexey Varlamov wrote:
> > 2006/11/30, Geir Magnusson Jr. <ge...@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
>
Re: [drlvm/classlib/jdktools] system property o.a.h.boot.class.path
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Alexey Varlamov wrote:
> 2006/11/30, Geir Magnusson Jr. <ge...@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?
> 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.
>
>>
>> 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.
>
>>
>> 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
Re: [drlvm/classlib/jdktools] system property o.a.h.boot.class.path
Posted by Alexey Varlamov <al...@gmail.com>.
2006/11/30, Geir Magnusson Jr. <ge...@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().
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