On Fri, Nov 14, 2008 at 8:24 PM, Regis <[EMAIL PROTECTED]> wrote: > IMHO, it isn't negative to modularity of Harmony itself at developing time, > but it is at deployment or runtime. For example, someone want to replace > concurrent module with another implementation, he just need to replace the > concurrent.jar, that's enough. But if we pack them into one big jar, he need > to unpack, replace and pack again. That also work, but isn't convenient and > straightforward.
We can offer a build option to provide separate JARs if that's desirable. Does anyone really need this feature? Thanks, xiaofeng > In general, a jar means this is relatively independent module, could be > removed or replaced if you want. If some jars are heavily coupled, it's > better to pack them into one. > > Best Regards, > Regis. > > Xiao-Feng Li wrote: >> >> Regis & Mingjian, would you explain why you think this approach is >> negative to modularity? >> >> Thanks, >> xiaofeng >> >> On Fri, Nov 14, 2008 at 11:30 AM, Regis <[EMAIL PROTECTED]> wrote: >>> >>> If we could reduce the number of pre-load jars from 40+ to 12 (listed on >>> the >>> JIRA), maybe I/O for loading jars is no longer a big bottleneck, while >>> the >>> less, the better :) >>> I just mean a careful trade-off needed between performance and >>> modularity. >>> >>> Best Regards, >>> Regis. >>> >>> Nathan Beyer wrote: >>>> >>>> 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 >>>>>> >> >> >> > -- http://xiao-feng.blogspot.com
