Community
Participate
Working Groups
In 0.7, the size of the Java runtime jar is 6.9MB. Based on some quick analysis, 90% of this file is made up of ICU4J. I know there were some previous conversations about ICU4J, but I would like to reconsider our options and figure out if there is a way to avoid including these files in every situation. A slim, tight runtime will avoid comments/concerns about EGL bloat, which is a key concern by people evaluating a technology like EGL. So, some questions .. 1) In what situations are the ICU4J files necessary? All the time? Some of the time? Only for specific locales? 2) How often do the ICU4J classes change? More often than the Java runtime classes? 3) Instead of merging ICU4J into the runtime jar at build time, what are the options for keeping the jars separate but including both in the project (assuming the ICU4J is needed in some scenarios)? 3A) If the ICU4J is only needed in certain scenarios, could the developer be prompted (e.g. checkbox when the project is created) to include it? I think we should consider this enhancement as part of the 0.8 Java optimization work ...
Related: Bug 355146
This needs to go near the top of the 0.8I3 list.
I've made updates so that we use the version of ICU that's installed with Eclipse (4.2 for Eclipse 3.6, 4.4 for Eclipse 3.7). The classpath container variable now includes this bundle reference, and a deployment hack to copy icu4j.jar when in development mode could now be removed (yay!). Changes: EDTCompilerIDEPlugin.java EDTRuntimeContainerEntry.java CopyJavaRuntimeResourcesOperation.java edt.runtime.java's manifest & build.properties Deleted the icu4j jar as well as customBuildCallbacks.xml which was packaging it into the runtime project.
close
