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.
