Some of those classes aren't HARMONY classes, they are ICU4J. Is repackaging the only way to solve this issue?
On Thu, Nov 13, 2008 at 1:40 AM, Wenlong Li <[EMAIL PROTECTED]> wrote: > Agree. > > Hello, all, > I collect the required classes/packages/jars in > http://issues.apache.org/jira/browse/HARMONY-6002. As we discussed, we > can package these classes into the bootstramp.jar, and handle other > classes/jars on demand. > > In my mind, we can parse all jars at startup, and only save the > manifest of each jar (except bootstramp.jar with all jars loaded > during startup). Later, when a new class is required, we can parse the > manifest to see this class in which jar, and then read all classes in > this jar to class cache (because I/O is also expensive, so I think we > should read all classes in this jar). As for implementation, I think > we can add code in LoadFromJarFile of classloader.cpp to support > on-demand jar/class parsing and loading. Is my understanding correct? > One more question is how to generate bootstramp.jar automatically? At > this moment, we can manually produce it, but it doesn't make sense for > a product. I guess we need make some modification on the modularity > under working_classlib\modules > > What do you think? > > Thx, > Wenlong > > On Wed, Nov 12, 2008 at 11:48 PM, Tim Ellison <[EMAIL PROTECTED]> wrote: >> Wenlong Li wrote: >>> Yes, I also noticed the manifest in each jar has keyword, like >>> export-package to define which packages are provided by this jar. I >>> think that would be one heuristics for us to decide parsing this jar >>> or not. I will try to add the on-demand jar parsing feature into >>> Harmony by using this rule information. >> >> Good idea. Or introduce the concept of a start-up classpath ... so you >> don't have to hard-code in the VM which packages are in the start-up >> sequence. >> >> Right now there is the bootclasspath and application classpath. We >> expect all the start-up classes plus more to be on the bootclasspath. >> >> But if we split that into the bootclasspath={start-up path + system >> path} classes then we can preload / process the JARs on the start-up >> classpath, and defer the parsing of those on the system classpath. Just >> as a start-up differentiator, the start-up+system JARs would of course >> all be part of the bootclasspath to the application. >> >> Just an idea... >> >> Regards, >> Tim >> >
