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: [classlib] [ldap] support for multiple VMs?
Date Tue, 15 Aug 2006 12:15:15 GMT
[snip]
> >> I wonder if DRLVM starts to use the same
> >> org.apache.harmony.boot.class.pathproperty wouldn't it be overwritten
> >> with luni initialization with value
> >> wihout kernel.jar?
> >>
> >
> > Besides, the luni init only recognizes "-Xbootclasspath:" runtime
> > parameter, but not "append"/"prepend" variants
> > ("-Xbootclasspath[/a|/p]:"). Yet another argument to unify and share
> > such code. Is there any reason to do this in classlib?
>
> Where else would you do it?
> As Tim mentioned earlier in this thread, we cannot do this in the launcher.
> Remember that the Harmony java launcher is not the only launcher that will
> ever run with Harmony code. If we put the bootclasspath.properties
> parsing code into the launcher, then that means anyone who writes their own
> launcher will get an empty bootclasspath unless they parse the file
> themselves.

I agree, launcher appears to be irrelevant to this task.

>
> IMHO, I would say that:
>  - the launcher should not too Harmony specific. Anything special we do
> there
> may well have consequences for other more generic launchers.
>  - the bootclasspath.properties file is read by classlib because it
> relates to the
> classlib component. It is a file that is specific to the Harmony
> classlib, and we should
> not expect any other component (launcher/VM) to have knowledge of it. If
> bootclasspath.properties parsing is moved out of classlib, there will also
> be a knock-on effect for VMs that use the Harmony classlib via
> classlibadapter,
> as they will no longer get the correct bootclasspath for free.
>  - the VM should prepend its kernel jars to the bootclasspath. They are
> a part of the
> VM half of the Harmony runtime (i.e. any other VM provider would have to
> provide
> them in its VM bundle, as the IBM VME does), and thus should be handled
> by the
> VM itself. At the moment the kernel jars are called luni-kernel.jar and
> security-kernel.jar,
> but there is nothing to stop another VM wanting to call them something
> different and
> still use Harmony classlib. If the addition of the kernel jars to the
> bootclasspath was
> done in classlib, then only the hardcoded names would be valid. I think
> this adds
> another contract between the classlib and VM that is unnecessary. All
> classlib should
> expect is that the VM will provide those classes at runtime.

Evidently there must be some contract between VM(s) and classlib,
defining which artifacts of the classlib VM should use. Currently, VM
have to load certain shared libraries and somehow obtain (ordered)
list of jars for bootstrap. Surely, there are at least 2 ways:
1) Read the bootclasspath.properties file directly;
2) Load particular dll/so and query for particular property value.
Besides, this list may be extended or modified by the VM itself or by
user via some arguments like -Xbootclasspath (or more specific ones).
This basically means that only VM may define the complete list
reliably, and in some cases may not ever ask the classlib for it.

Now let's clarify usage context for this property. I'm aware of the following:
- it is used in classlib to lookup resources like available locales;
- it is used in classlib to spawn another VM process (via
-Xbootclasspath and such);
- it is quite possibly used by a VM to maintain actual bootpath;
Looking at the usage points, I'd say we better sync exact value of
"boot.class.path" property in classlib and actual bootclasspath in VM,
which includes all kernel and user's jars. This appears to be another
part of VM<>classlib contract - i.e. VM should be aware of this
property and when it is created and should update it with complete
value at certain moment. I guess IBM VME follows to this exactly.

One more issue, list of jars may be needed in VM already during
processing of init arguments, but loading classlib libraries is a bit
premature until arguments are processed completely.

Summing up the above, a compromise solution would be to provide a
common property-file-parser somewhere in a shared portlib and leave
everything else to VM (or classlibadapter - which is effectively VM
component). All the more there may be other VM-specific property
files, the parser would be handy anyway. And with proper instrumental
support, the "knock-on effect" would be quite minimal.

What do you think?

--
Alexey

>
> I think that what really needs to be done is to improve the code that is
> already, IMO,
> in the right place, rather than move it elsewhere.
>
> Regards,
> Oliver
>
> >
> > --
> > Alexey
> >
> >
> >>
> >> If you want the code to run on the Sun implementation too then you
> >> > should *also* search the sun.boot.class.path, and of course be
> >> tolerant
> >> > of o.a.harmony... or sun.boot... being absent.  Is running on Sun a
> >> goal
> >> > for you?  It's not something that we would require for including the
> >> > LDAP code in Harmony.
> >> >
> >> > Regards,
> >> > Tim
> >> >
> >> >
> >> --
> >> Gregory Shimansky, Intel Middleware Products Division
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> --
> Oliver Deakin
> IBM United Kingdom Limited
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message