On Sunday 25 June 2006 01:38 Tim Ellison wrote: > > The only place you should find stubs of classes should be in > > luni-kernel-stubs.jar and security-kernel-stubs.jar (they used to be in > > one file but now they are split.) However, due to an oversight in the > > patternsets, and the fact that the classes build to a common directory, > > they also get included in luni.jar and security.jar. > > > > For the IBM VME, the stubs are replaced by the jars listed > > injre/bin/default/clearvm.properties - i.e. luni-kernel.jar and > > security-kernel.jar. > > > > I should mention that String is intended to be in luni.jar. It was > > agreed some time back to move String out of the set of kernel classes > > in to luni. (Although it was always intended that a VM implementation > > could override the String if it wished to do so.) > > Yep, indeed any VM can override any class, provided they match the > contract of course (they are /required/ to implement the kernel clsses). > All the more reason why the VM's kernel.jar(s) should be ahead on the BCP.
This is my idea to update drlvm bootclasspath.properties file parser. First to unconditionally include kernel.jar and then all of the files mentioned in bootclasspath.properties excluding OSGI stuff. I am going to create a JIRA tomorrow. Then it will be possible to get rid of drlvm/trunk/vm/vmcore/src/init/bootclasspath.properties file and use the properties file provided by classlib. -- 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]
