[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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Oliver Deakin IBM United Kingdom Limited --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
