harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: [classlib] [ldap] support for multiple VMs?
Date Mon, 14 Aug 2006 10:54:00 GMT
Alexey Varlamov wrote:
> 2006/8/11, Gregory Shimansky <gshimansky@gmail.com>:
>> 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).
>> DRLVM sets two propeties with the same value. The one which is used 
>> by VM is
>> vm.boot.class.path and another added for compatibility with some
>> applications is sun.boot.class.path. It is not used inside of VM. I 
>> compared
>> values with org.apache.harmony.boot.class.path with is set in 
>> classlib luni
>> and foind that the only difference is with kernel.jar absent in it and
>> present in DRLVM properties. It is logical because they both read the 
>> same
>> bootclasspath.properties file but VM also adds kernel.jar before 
>> everything.
>> 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 

IMHO, I would say that:
 - the launcher should not too Harmony specific. Anything special we do 
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 
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 
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 
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.

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.


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

View raw message