RFR [JEP 220] Modular Run-Time Images - compact profiles footprint

[Naoto Sato]

Quick question. Why is jdk.localedata module included in the compact 
profiles? The data there used to be in lib/ext/localedata.jar and 
lib/ext/cldrdata.jar which weren't included in those compact profiles.

Naoto

On 12/4/14, 5:48 AM, Alan Bateman wrote:
> On 04/12/2014 12:58, Xerxes Rånby wrote:
>> The footprint of the compact profiles have been inflated by ~12Mb each
>> after the JEP 220 changes.
>>
>> before
>> # du -s -h j2re-compact1-image
>> 17.9M    j2re-compact1-image
>> # du -s -h j2re-compact2-image
>> 28.7M    j2re-compact2-image
>> # du -s -h j2re-compact3-image
>> 35.5M    j2re-compact3-image
>>
>> after
>> # du -s -h jre-compact1
>> 31.3M    jre-compact1
>> # du -s -h jre-compact2
>> 41.5M    jre-compact2
>> # du -s -h jre-compact3
>> 47.4M    jre-compact3
>>
>> The attached file compact1.diff.tar.gz contains the list diff of the
>> files bundled in the
>> j2re-compact1-image/lib/rt.jar compared to jre-compact1/lib/*.jimage
>> most of the class diff is located in
>>
>> com/sun/security/ntlm
>> com/sun/crypto
>> javax/crypto
>> sun/net/www/protocol/http/ntlm
>> sun/net/www/protocol/ftp
>> sun/net/www/protocol/mailto
>> sun/net/ftp
>> sun/net/smtp
>> sun/net/dns
>> sun/util/resources <- a lot of extra internationalized classes
>> sun/security/ssl
>> sun/security/ec
>> sun/security/pkcs11
>> sun/text/resources <- a lot of extra internationalized classes
>
> The release file in the top directory of the runtime image gives a good
> indication as to what is going on. If you look at the value of the
> MODULES key then you'll the see the modules that are actually linked in.
> For jre-compact1 then you should see a line like this:
>
> MODULES="java.base jdk.localedata java.scripting java.logging
> java.compact1 jdk.crypto.ec jdk.crypto.pkcs11"
>
> The java.* modules are the modules that make up compact1, the jdk.*
> modules are additional service providers linked into the image. The
> service providers aren't strictly required to be there, we've just
> chosen to include them so that "profiles" make target gives us images
> that approximately correspond to what we had previously. If you want to
> play around with leaving them out then look in make/Images.gmk and
> COMPACT_EXTRA_MODULES. Going forward then I expect we will have a tool
> that will allow for a lot more flexibility to create images with just
> the modules that you want (and their transitive dependences of course).
>
> So I think the bulk of the difference that you are seeing is explained
> by the service providers and mostly jdk.localedata. That module is big
> and contains all of non-US_en JRE locale data and all of the CLDR data.
> We still need to figure out what how to split this, you might recall the
> discussion on i18n-dev and jigsaw-dev where they was some recent
> discussion on this. It's also listed in JEP 200 as an open issue.
>
> So when comparing to JDK 8 or previous JDK 9 compact profile builds then
> think of the new images has having the equivalent of both localedata.jar
> and cldrdata.jar present. If you edit COMPACT_EXTRA_MODULES to remove
> jdk.localdata.jar then it should make it easier to compare.
>
> Another thing to point out is that rt.jar isn't everything in the legacy
> image. You need to take account of jce.jar, jsse.jar and
> ext/sunjce_provider.jar. That should explain the javax.crypto,
> com.sun.crypto and sun.security.ssl packages in your list.
>
> Another thing to mention is the java.base module currently contains a
> few legacy items that we previously stripped out of the profiles builds
> in JDK 8. We still need to figure out what to do with these. The ftp and
> smtp protocol handlers come to mind, also the NTLM htto authentication
> scheme. At one point we have a "compat" module for legacy stuff that
> people might want for compatibility reasons. So expect some tweaking
> here, we know people focused on footprint will not thank us for bringing
> back legacy stuff.
>
> A few final point to mention. (a) there are a few additional launchers
> (and maybe debug info/diz files if build with those) that were not there
> previously. This is a consequence of modularization where modules with
> launchers and where the classes for those launchers were previously in
> tools.jar. (b) there are some additional classes that didn't previously
> exist in JDK 9, this is to support the new image format. I expect some
> churn with those over the next few months.
>
> So hopefully this helps to explain what you are seeing. I think folks
> might be interested in see j2re-image vs. jre and j2sdk-image vs. jdk
> sizes too.
>
> -Alan.