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: [general] *.boot.class.path propoerty setting (Was Re: [classlib] [ldap] support for multiple VMs?)
Date Fri, 11 Aug 2006 16:55:42 GMT
2006/8/11, Geir Magnusson Jr <geir@pobox.com>:
> I was going to talk about the exact thing when I had a chance, so glad
> you beat me to it.  I'm just changing the subject line so it's clearer.
>
> Inline.
>
> Alexey Varlamov wrote:
> > A bit offttopic for this thread, but I'd like to discuss the following
> > points for the boot.class.path property:
> > 1) Whose responsibility is to set this property (launcher, VM or
> > classlib)? Now we have at least 3 implementations:
> >  a) readClassPathFromPropertiesFile() in
> > classlib\modules\archive\src\main\native\archive\windows\jclglob_harmony.c
> >  b) readClassPathFromPropertiesFile() in
> > classlib\modules\luni\src\main\native\luni\shared\luniglob.c
> >  c) load_full_api_files_path_names_list() in
> > drlvm\vm\vmcore\src\init\properties.cpp
> > BTW, the first 2 seems to be just copy-paste copies. I believe there
> > should be just single agent doing this task, most natural candidate is
> > shared VM launcher.
>
> I also thought the launcher was the right place, but not so sure, as you
>  wouldn't want to handcuff the VM implementations as to what kinds of
> features they can add here.  Maybe VM launcher sets it originally, but
> the VM is free to override?
>
I suggest that launcher pass the bootclasspath string among other
VMOptions. It can even (re)use "-Xbootclasspath:" argument - that is,
such argument would be specified either by user or by the launcher
itself.

> >
> > 2) Current parsers of the bootclasspath.properties are fragile in
> > relation to format of this file: the file must end with line delimiter
> > and must have strict platform line delimiters, otherwise jvm just
> > hangs. Should I file new JIRA or this is intentional?
>
> Please file a JIRA.  Hanging can never be intentional.  :)
>
> geir
>
> >
> >
> > 2006/8/11, Tim Ellison <t.p.ellison@gmail.com>:
> >> Daniel Gandara wrote:
> >> > Hi all,
> >> >
> >> > We are working on the javax.naming.ldap and we are facing the
> >> > following issue when thinking about supporting multiple VMs.
> >> > Following the SPEC there is a method createExtendedResponse in the
> >> > StartTlsRequest class which states that the returning object must be
> >> > an instance of a concrete subclass of StartTlsResponse and must have
> >> > a public zero-argument constructor. The concrete subclass is
> >> > determined by reading the configuration file located in
> >> > META-INF/services/javax.naming.ldap.StartTlsResponse (see
> >> >
> >> http://java.sun.com/j2se/1.5.0/docs/api/javax/naming/ldap/StartTlsRequest.html)
> >>
> >> >
> >> > The search for this configuration file is done by looking in the
> >> > classpath, java.home and user.dir; also the Xbootclasspath should be
> >> > inspected, and that seems to be a problematic situation, since there
> >> > is not a standard property to look for its value. Different VM
> >> > implementations have different property names for the boot class path
> >> > value. In the old Harmony VM implementation was
> >> > com.ibm.oti.system.class.path; in the new one is
> >> > org.apache.harmony.boot.class. The property name in the Sun's VM is
> >> > sun.boot.class.path. We are wondering which property name to use in
> >> > the code. At first sight the Harmony new VM implementation property
> >> > seems to be the better option, but maybe looking for the other
> >> > properties will be interesting for compatibility purposes.
> >> >
> >> > We would be very interested in opinions.
> >>
> >> I'd ignore the com.ibm property and look through the path defined by
> >> org.apache.harmony.boot.class.path
> >>
> >> I don't know what property is set by the DRLVM / JCHEVM / etc., but it
> >> would be good if they set the same property (maybe in addition to their
> >> current property).
> >>
> >> 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
> >>
> >> --
> >>
> >> Tim Ellison (t.p.ellison@gmail.com)
> >> IBM Java technology centre, UK.
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
> >
> >
>
> ---------------------------------------------------------------------
> 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