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

[Alan Bateman]

On 05/12/2014 17:57, Sergey Bylokhov wrote:

On 04.12.2014 20:11, Alan Bateman wrote:
We've now moved to world where the runtime images are created from a 
set of modules and this should give a lot of flexibility once. We're 
just not there yet with locale data so we have to temporarily link in 
the big jdk.localedata module so that the profiles images have all 
locales.
Just curious, how will we track the size of modules? Probably we can 
save this information during the build time, so regressions will be 
found easily?
Once we are a bit further then I expect we will generate a directory of 
modules, format TBD. This will be important to have when creating images 
outside of the JDK build environment, say a custom image with your 
application, some libraries and their transitive dependences. That might 
be the time to track the size, although it would really be just an 
indication, it may be very different when linked in to the eventual 
image (due to compression and other transformations that might happen at 
link time).


-Alan

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

[Sergey Bylokhov]

On 04.12.2014 20:11, Alan Bateman wrote:
We've now moved to world where the runtime images are created from a 
set of modules and this should give a lot of flexibility once. We're 
just not there yet with locale data so we have to temporarily link in 
the big jdk.localedata module so that the profiles images have all 
locales.
Just curious, how will we track the size of modules? Probably we can 
save this information during the build time, so regressions will be 
found easily?




-Alan.



--
Best regards, Sergey.

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

[Alan Bateman]

On 04/12/2014 16:38, Naoto Sato wrote:
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
The "profiles" make target on JDK 8 (and JDK 9 before yesterday) always 
included localedata.jar in the images. I would expect this would be 
pruned or removed before deploying to an embedded device of course, same 
thing for the security providers that get included by default.


We've now moved to world where the runtime images are created from a set 
of modules and this should give a lot of flexibility once. We're just 
not there yet with locale data so we have to temporarily link in the big 
jdk.localedata module so that the profiles images have all locales.


-Alan.

Re: RFR [JEP 220] Modular Run-Time Images

[Magnus Ihse Bursie]

On 2014-11-20 22:39, Chris Hegarty wrote:

This is a review request for the changes for JEP 220: Modular Run-Time Images 
[1].

There are a number of individuals responsible for these changes. Some, possibly 
not all, are explicitly listed in the 'To' section of this mail, and they will 
help address any comments arising from this review request.

The new run-time image structure is defined in JEP 220 [1], and can be seen as 
a result of building the staging forest [2], or in the early access builds [3].

Webrevs:
http://cr.openjdk.java.net/~chegar/8061971/00/


I have thoroughly reviewed all the build changes, and they look good to 
me, with the following remarks.


It would have been nice to use the new "wrapper" based approach for all 
module-phase specific details -- this is done now for all phases except 
gensrc and rmic. But this is not necessary for the patch to work, and 
can be addressed later on.


We also need to update configure to accept a module-based JDK as a boot 
JDK. In the patch, this is done sort-of -- we can run a bootcycle build 
with the new module-based JDK, but we will not accept it as an initial 
boot JDK. But this too can be fixed later on.


And of course there is always some syntax issues. :-) In 
langtools/make/gensrc/Gensrc-jdk.*.gmk, there are several calls of the 
pattern:

$(eval $(call SetupVersionProperties,JAVAP_VERSION, ...))
$(eval $(call SetupCompileProperties,COMPILE_PROPERTIES, ...))
These should have a space following the comma to adhere to the 
recommended style. But once again, I'm okay with fixing this in a follow up.


/Magnus

Re: RFR [JEP 220] Modular Run-Time Images - fix zero build

[Xerxes Rånby]

Hi Chris!

The build changes introduced a new dependency that sa-jdi.jar is always 
built.


The sa-jdi.jar do not get built  for Zero and Itanium builds.
Zero is built using the --with-jvm-interpreter=cpp 
--with-jvm-variants=zero configure options.


The sa-jdi.jar also do not exist if you use the --with-import-hotspot= 
to import alternative OpenJDK JVM such as

a pre-compiled CACAO JVM or JamVM libjvm.so .

I would suggest to change the jdk/make/Import.gmk and 
jdk/make/gensrc/Gensrc-jdk.jdi.gmk to first check if sa-jdi.jar
exist before adding it to the SA_TARGETS and GENSRC_JDK_JDI something 
like this:


Index: openjdk-jdk9-b38/jdk/make/Import.gmk
===
--- openjdk-jdk9-b38.orig/jdk/make/Import.gmk   2014-11-17 17:34:13.830175424 
+0100
+++ openjdk-jdk9-b38/jdk/make/Import.gmk2014-11-18 09:10:25.420715300 
+0100
@@ -221,6 +221,8 @@
 # even if zip is already unpacked.
 $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services: 
$(HOTSPOT_DIST)/lib/sa-jdi.jar
 
+# sa-jdi.jar do not exist for Itanium and zero

+if [ -a $(HOTSPOT_DIST)/lib/sa-jdi.jar ] ; \
 SA_TARGETS += $(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/_the.sa.jar.unpacked \
 $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services
 
Index: openjdk-jdk9-b38/jdk/make/gensrc/Gensrc-jdk.jdi.gmk

===
--- openjdk-jdk9-b38.orig/jdk/make/gensrc/Gensrc-jdk.jdi.gmk2014-11-18 
08:57:26.504852865 +0100
+++ openjdk-jdk9-b38/jdk/make/gensrc/Gensrc-jdk.jdi.gmk 2014-11-18 
09:10:43.348804201 +0100
@@ -78,12 +78,10 @@
 
$(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector
$(install-file)
 
+# sa-jdi.jar do not exist for Itanium and zero

+if [ -a $(HOTSPOT_DIST)/lib/sa-jdi.jar ] ; \
 GENSRC_JDK_JDI += 
$(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector
 \
 
$(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/META-INF/services/com.sun.jdi.connect.Connector

 
Cheers

Xerxes




From: Chris Hegarty 
Subject: RFR [JEP 220] Modular Run-Time Images
Date: 20 November 2014 21:39:14 GMT
To: jigsaw-dev , jdk9-dev , build-dev , Alan Bateman , 
Alex Buckley , Chris Hegarty , Erik Joelsson , Jonathan Gibbons 
, Karen Kinnear , "Jim Laskey (Oracle)" , Magnus Ihse Bursie 
, Mandy Chung , Mark Reinhold , Paul Sandoz , "A. 
Sundararajan" 

This is a review request for the changes for JEP 220: Modular Run-Time Images 
[1].

There are a number of individuals responsible for these changes. Some, possibly 
not all, are explicitly listed in the 'To' section of this mail, and they will 
help address any comments arising from this review request.

The new run-time image structure is defined in JEP 220 [1], and can be seen as 
a result of building the staging forest [2], or in the early access builds [3].

Webrevs:
   http://cr.openjdk.java.net/~chegar/8061971/00/

Due to the significant impact of these changes, a JDK 9 promotion has been 
tentatively reserved for their integration. All comments are welcome, although 
given the nature of the changes then we might have to create separate issues in 
JIRA to address some of them later in jdk9/dev.

-Chris.

[1] http://openjdk.java.net/jeps/220
[2] http://hg.openjdk.java.net/jigsaw/m2/
[3] http://openjdk.java.net/projects/jigsaw/ea

Re: 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.9Mj2re-compact1-image
# du -s -h j2re-compact2-image
28.7Mj2re-compact2-image
# du -s -h j2re-compact3-image
35.5Mj2re-compact3-image

after
# du -s -h jre-compact1
31.3Mjre-compact1
# du -s -h jre-compact2
41.5Mjre-compact2
# du -s -h jre-compact3
47.4Mjre-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.

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

[Alan Bateman]

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.9Mj2re-compact1-image
# du -s -h j2re-compact2-image
28.7Mj2re-compact2-image
# du -s -h j2re-compact3-image
35.5Mj2re-compact3-image

after
# du -s -h jre-compact1
31.3Mjre-compact1
# du -s -h jre-compact2
41.5Mjre-compact2
# du -s -h jre-compact3
47.4Mjre-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.

Re: RFR [JEP 220] Modular Run-Time Images - fix zero build

[Dave Pointon]

Yep ,

I like that even more, Erik :-)

--
Dave Pointon FIAP MBCS

Now I saw, tho' too late, the folly of beginning a work before we count the
cost and before we we judge rightly of our strength to go thro' with it -
Robinson Crusoe

On 3 December 2014 at 17:46, Erik Joelsson  wrote:

>  Yes, it can be modified. My preferred variant for file existence checking
> in make is "ifneq ($(wildcard /path/to/file), )". Also, in
> Gensrc-jdk.jdi.gmk, I would probably like some other logical condition to
> check on than sa-jdi.jar. We will address this at some point soon.
>
> /Erik
>
> On 2014-12-03 15:47, Dave Pointon wrote:
>
>  Hmmm ,
>
>  Would it not be possible to modify Xerxes' suggested patch to do
> something along the lines of ...
>
> # sa-jdi.jar do not exist for Itanium and zero
> ifeq ($(shell if test -a $(HOTSPOT_DIST)/lib/sa-jdi.jar; then echo N;
> fi),N)
>   SA_TARGETS += \
> $(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/_the.sa.jar.unpacked \
> $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services
>  endif
>
>  Just a thought
>
>  --
> Dave Pointon FIAP MBCS -
> ​ contractor engaged by IBM​
>
>
> Now I saw, tho' too late, the folly of beginning a work before we count
> the cost and before we we judge rightly of our strength to go thro' with it
> - Robinson Crusoe
>
> On 3 December 2014 at 14:30, Erik Joelsson 
> wrote:
>
>> Hello Xerxes,
>>
>> Thanks for the suggestion. I have created
>> https://bugs.openjdk.java.net/browse/JDK-8066589 to track this issue.
>> Unfortunately we won't have time to fix it before pushing JEP 220 to jdk9.
>> I hope this won't inconvenience you too much.
>>
>> Your suggested patch does correctly highlight the problem areas, but will
>> not work since gnu make does not accept shell logic outside of recipes or
>> $(shell ...) constructs.
>>
>> /Erik
>>
>> ​ ​
>>
>
>
>

Re: RFR [JEP 220] Modular Run-Time Images - fix zero build

[Erik Joelsson]

Yes, it can be modified. My preferred variant for file existence 
checking in make is "ifneq ($(wildcard /path/to/file), )". Also, in 
Gensrc-jdk.jdi.gmk, I would probably like some other logical condition 
to check on than sa-jdi.jar. We will address this at some point soon.


/Erik

On 2014-12-03 15:47, Dave Pointon wrote:

Hmmm ,

Would it not be possible to modify Xerxes' suggested patch to do 
something along the lines of ...


# sa-jdi.jar do not exist for Itanium and zero
ifeq ($(shell if test -a $(HOTSPOT_DIST)/lib/sa-jdi.jar; then echo N; 
fi),N)

  SA_TARGETS += \
$(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/_the.sa.jar.unpacked \
$(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa 
.services

endif

Just a thought

--
Dave Pointon FIAP MBCS -
​ contractor engaged by IBM​


Now I saw, tho' too late, the folly of beginning a work before we 
count the cost and before we we judge rightly of our strength to go 
thro' with it - Robinson Crusoe


On 3 December 2014 at 14:30, Erik Joelsson > wrote:


Hello Xerxes,

Thanks for the suggestion. I have created
https://bugs.openjdk.java.net/browse/JDK-8066589 to track this
issue. Unfortunately we won't have time to fix it before pushing
JEP 220 to jdk9. I hope this won't inconvenience you too much.

Your suggested patch does correctly highlight the problem areas,
but will not work since gnu make does not accept shell logic
outside of recipes or $(shell ...) constructs.

/Erik

​ ​

Re: RFR [JEP 220] Modular Run-Time Images - fix zero build

[Dave Pointon]

Hmmm ,

Would it not be possible to modify Xerxes' suggested patch to do something
along the lines of ...

# sa-jdi.jar do not exist for Itanium and zero
ifeq ($(shell if test -a $(HOTSPOT_DIST)/lib/sa-jdi.jar; then echo N; fi),N)
  SA_TARGETS += \
$(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/_the.sa.jar.unpacked \
$(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services
endif

Just a thought

--
Dave Pointon FIAP MBCS -
​ contractor engaged by IBM​


Now I saw, tho' too late, the folly of beginning a work before we count the
cost and before we we judge rightly of our strength to go thro' with it -
Robinson Crusoe

On 3 December 2014 at 14:30, Erik Joelsson  wrote:

> Hello Xerxes,
>
> Thanks for the suggestion. I have created https://bugs.openjdk.java.net/
> browse/JDK-8066589 to track this issue. Unfortunately we won't have time
> to fix it before pushing JEP 220 to jdk9. I hope this won't inconvenience
> you too much.
>
> Your suggested patch does correctly highlight the problem areas, but will
> not work since gnu make does not accept shell logic outside of recipes or
> $(shell ...) constructs.
>
> /Erik
>
> ​​
>

Re: RFR [JEP 220] Modular Run-Time Images - fix zero build

[Erik Joelsson]

Hello Xerxes,

Thanks for the suggestion. I have created 
https://bugs.openjdk.java.net/browse/JDK-8066589 to track this issue. 
Unfortunately we won't have time to fix it before pushing JEP 220 to 
jdk9. I hope this won't inconvenience you too much.


Your suggested patch does correctly highlight the problem areas, but 
will not work since gnu make does not accept shell logic outside of 
recipes or $(shell ...) constructs.


/Erik

On 2014-12-03 14:37, Xerxes Rånby wrote:

Hi Chris!

The build changes introduced a new dependency that sa-jdi.jar is 
always built.


The sa-jdi.jar do not get built  for Zero and Itanium builds.
Zero is built using the --with-jvm-interpreter=cpp 
--with-jvm-variants=zero configure options.


The sa-jdi.jar also do not exist if you use the --with-import-hotspot= 
to import alternative OpenJDK JVM such as

a pre-compiled CACAO JVM or JamVM libjvm.so .

I would suggest to change the jdk/make/Import.gmk and 
jdk/make/gensrc/Gensrc-jdk.jdi.gmk to first check if sa-jdi.jar
exist before adding it to the SA_TARGETS and GENSRC_JDK_JDI something 
like this:


Index: openjdk-jdk9-b38/jdk/make/Import.gmk
===
--- openjdk-jdk9-b38.orig/jdk/make/Import.gmk   2014-11-17 
17:34:13.830175424 +0100
+++ openjdk-jdk9-b38/jdk/make/Import.gmk2014-11-18 
09:10:25.420715300 +0100

@@ -221,6 +221,8 @@
 # even if zip is already unpacked.
 $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services: 
$(HOTSPOT_DIST)/lib/sa-jdi.jar


+# sa-jdi.jar do not exist for Itanium and zero
+if [ -a $(HOTSPOT_DIST)/lib/sa-jdi.jar ] ; \
 SA_TARGETS += 
$(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/_the.sa.jar.unpacked \

$(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services

Index: openjdk-jdk9-b38/jdk/make/gensrc/Gensrc-jdk.jdi.gmk
===
--- openjdk-jdk9-b38.orig/jdk/make/gensrc/Gensrc-jdk.jdi.gmk 
2014-11-18 08:57:26.504852865 +0100
+++ openjdk-jdk9-b38/jdk/make/gensrc/Gensrc-jdk.jdi.gmk 2014-11-18 
09:10:43.348804201 +0100

@@ -78,12 +78,10 @@
$(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector
$(install-file)

+# sa-jdi.jar do not exist for Itanium and zero
+if [ -a $(HOTSPOT_DIST)/lib/sa-jdi.jar ] ; \
 GENSRC_JDK_JDI += 
$(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector 
\

$(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/META-INF/services/com.sun.jdi.connect.Connector


Cheers
Xerxes




From: Chris Hegarty 
Subject: RFR [JEP 220] Modular Run-Time Images
Date: 20 November 2014 21:39:14 GMT
To: jigsaw-dev , jdk9-dev 
, build-dev , 
Alan Bateman , Alex Buckley 
, Chris Hegarty , 
Erik Joelsson , Jonathan Gibbons 
, Karen Kinnear 
, "Jim Laskey (Oracle)" 
, Magnus Ihse Bursie 
, Mandy Chung 
, Mark Reinhold , 
Paul Sandoz , "A. Sundararajan" 



This is a review request for the changes for JEP 220: Modular 
Run-Time Images [1].


There are a number of individuals responsible for these changes. 
Some, possibly not all, are explicitly listed in the 'To' section of 
this mail, and they will help address any comments arising from this 
review request.


The new run-time image structure is defined in JEP 220 [1], and can 
be seen as a result of building the staging forest [2], or in the 
early access builds [3].


Webrevs:
   http://cr.openjdk.java.net/~chegar/8061971/00/

Due to the significant impact of these changes, a JDK 9 promotion 
has been tentatively reserved for their integration. All comments 
are welcome, although given the nature of the changes then we might 
have to create separate issues in JIRA to address some of them later 
in jdk9/dev.


-Chris.

[1] http://openjdk.java.net/jeps/220
[2] http://hg.openjdk.java.net/jigsaw/m2/
[3] http://openjdk.java.net/projects/jigsaw/ea

Re: RFR [JEP 220] Modular Run-Time Images

[Chris Hegarty]

I’ve taken a pass over the non-build changes and don’t see anything of concern. 
 I put them though our internal build and test system, and the results look 
positive.

-Chris.

On 20 Nov 2014, at 21:39, Chris Hegarty  wrote:

> This is a review request for the changes for JEP 220: Modular Run-Time Images 
> [1].
> 
> There are a number of individuals responsible for these changes. Some, 
> possibly not all, are explicitly listed in the 'To' section of this mail, and 
> they will help address any comments arising from this review request.
> 
> The new run-time image structure is defined in JEP 220 [1], and can be seen 
> as a result of building the staging forest [2], or in the early access builds 
> [3].
> 
> Webrevs:
>   http://cr.openjdk.java.net/~chegar/8061971/00/
> 
> Due to the significant impact of these changes, a JDK 9 promotion has been 
> tentatively reserved for their integration. All comments are welcome, 
> although given the nature of the changes then we might have to create 
> separate issues in JIRA to address some of them later in jdk9/dev.
> 
> -Chris.
> 
> [1] http://openjdk.java.net/jeps/220
> [2] http://hg.openjdk.java.net/jigsaw/m2/
> [3] http://openjdk.java.net/projects/jigsaw/ea

Re: RFR [JEP 220] Modular Run-Time Images

[Chris Hegarty]

Thanks for reviewing these changes Joe.

On 21/11/14 19:55, huizhe wang wrote:

Hi Chris,

The jaxp changes look good as well. Only a couple of debug info in
javax/xml/datatype/FactoryFinder.java and
javax/xml/parsers/FactoryFinder.java may be fixed. They were wrong
originally. You've fixed it in other FactoryFinders.
   "found in $java.home/jaxp.properties,
   "found in $java.home/conf/jaxp.properties,


This has been fixed in jigsaw/m2.

-Chris



Thanks,
Joe

On 11/20/2014 1:41 PM, Chris Hegarty wrote:

From: Chris Hegarty 
Subject: RFR [JEP 220] Modular Run-Time Images
Date: 20 November 2014 21:39:14 GMT
To: jigsaw-dev , jdk9-dev
, build-dev ,
Alan Bateman , Alex Buckley
, Chris Hegarty ,
Erik Joelsson , Jonathan Gibbons
, Karen Kinnear
, "Jim Laskey (Oracle)"
, Magnus Ihse Bursie
, Mandy Chung
, Mark Reinhold ,
Paul Sandoz , "A. Sundararajan"


This is a review request for the changes for JEP 220: Modular
Run-Time Images [1].

There are a number of individuals responsible for these changes.
Some, possibly not all, are explicitly listed in the 'To' section of
this mail, and they will help address any comments arising from this
review request.

The new run-time image structure is defined in JEP 220 [1], and can
be seen as a result of building the staging forest [2], or in the
early access builds [3].

Webrevs:
   http://cr.openjdk.java.net/~chegar/8061971/00/

Due to the significant impact of these changes, a JDK 9 promotion has
been tentatively reserved for their integration. All comments are
welcome, although given the nature of the changes then we might have
to create separate issues in JIRA to address some of them later in
jdk9/dev.

-Chris.

[1] http://openjdk.java.net/jeps/220
[2] http://hg.openjdk.java.net/jigsaw/m2/
[3] http://openjdk.java.net/projects/jigsaw/ea

Re: RFR [JEP 220] Modular Run-Time Images

[Chris Hegarty]

On 23/11/14 23:15, Magnus Ihse Bursie wrote:


On 2014-11-20 22:39, Chris Hegarty wrote:

This is a review request for the changes for JEP 220: Modular Run-Time
Images [1].

There are a number of individuals responsible for these changes. Some,
possibly not all, are explicitly listed in the 'To' section of this
mail, and they will help address any comments arising from this review
request.

The new run-time image structure is defined in JEP 220 [1], and can be
seen as a result of building the staging forest [2], or in the early
access builds [3].

Webrevs:
http://cr.openjdk.java.net/~chegar/8061971/00/


I have thoroughly reviewed all the build changes, and they look good to
me, with the following remarks.


Thanks for taking the time to review the build changes Magnus.


It would have been nice to use the new "wrapper" based approach for all
module-phase specific details -- this is done now for all phases except
gensrc and rmic. But this is not necessary for the patch to work, and
can be addressed later on.

We also need to update configure to accept a module-based JDK as a boot
JDK. In the patch, this is done sort-of -- we can run a bootcycle build
with the new module-based JDK, but we will not accept it as an initial
boot JDK. But this too can be fixed later on.

And of course there is always some syntax issues. :-) In
langtools/make/gensrc/Gensrc-jdk.*.gmk, there are several calls of the
pattern:
$(eval $(call SetupVersionProperties,JAVAP_VERSION, ...))
$(eval $(call SetupCompileProperties,COMPILE_PROPERTIES, ...))
These should have a space following the comma to adhere to the
recommended style. But once again, I'm okay with fixing this in a follow
up.


It is up to you. If some of these changes are benign, then maybe you 
could work with Erik to get them into jigsaw/m2, otherwise we can fix 
them in jdk9/dev.


Thanks again,
-Chris.

Re: RFR [JEP 220] Modular Run-Time Images

[huizhe wang]

Hi Chris,

The jaxp changes look good as well. Only a couple of debug info in 
javax/xml/datatype/FactoryFinder.java and 
javax/xml/parsers/FactoryFinder.java may be fixed. They were wrong 
originally. You've fixed it in other FactoryFinders.

  "found in $java.home/jaxp.properties,
  "found in $java.home/conf/jaxp.properties,

Thanks,
Joe

On 11/20/2014 1:41 PM, Chris Hegarty wrote:

From: Chris Hegarty 
Subject: RFR [JEP 220] Modular Run-Time Images
Date: 20 November 2014 21:39:14 GMT
To: jigsaw-dev , jdk9-dev , build-dev , Alan Bateman , 
Alex Buckley , Chris Hegarty , Erik Joelsson , Jonathan Gibbons 
, Karen Kinnear , "Jim Laskey (Oracle)" , Magnus Ihse Bursie 
, Mandy Chung , Mark Reinhold , Paul Sandoz , "A. 
Sundararajan" 

This is a review request for the changes for JEP 220: Modular Run-Time Images 
[1].

There are a number of individuals responsible for these changes. Some, possibly 
not all, are explicitly listed in the 'To' section of this mail, and they will 
help address any comments arising from this review request.

The new run-time image structure is defined in JEP 220 [1], and can be seen as 
a result of building the staging forest [2], or in the early access builds [3].

Webrevs:
   http://cr.openjdk.java.net/~chegar/8061971/00/

Due to the significant impact of these changes, a JDK 9 promotion has been 
tentatively reserved for their integration. All comments are welcome, although 
given the nature of the changes then we might have to create separate issues in 
JIRA to address some of them later in jdk9/dev.

-Chris.

[1] http://openjdk.java.net/jeps/220
[2] http://hg.openjdk.java.net/jigsaw/m2/
[3] http://openjdk.java.net/projects/jigsaw/ea

Re: RFR [JEP 220] Modular Run-Time Images

[Chris Hegarty]

On 21 Nov 2014, at 16:51, Sean Mullan  wrote:

> The JDK security related changes look fine to me. The 
> test/java/net/URLPermission/policy.* files only have copyright changes for 
> some reason.

Thanks for reviewing the security related changes Sean.

The jdk/test/java/net/URLPermission/policy.* files were changed in jigsaw/m2, 
at one point. Subsequent changes sync’ed from the JDK 9 mainline rendered these 
changes redundant, but the copyright, year range, change remained. The changes 
in these files are unnecessary and I have reversed them in jigsaw/m2 [1]

Thanks,
-Chris.

[1] http://hg.openjdk.java.net/jigsaw/m2/jdk/rev/3032b0232660


> --Sean
> 
> 
> On 11/20/2014 04:41 PM, Chris Hegarty wrote:
>> 
>>> From: Chris Hegarty 
>>> Subject: RFR [JEP 220] Modular Run-Time Images
>>> Date: 20 November 2014 21:39:14 GMT
>>> To: jigsaw-dev , jdk9-dev 
>>> , build-dev , Alan 
>>> Bateman , Alex Buckley , 
>>> Chris Hegarty , Erik Joelsson 
>>> , Jonathan Gibbons , 
>>> Karen Kinnear , "Jim Laskey (Oracle)" 
>>> , Magnus Ihse Bursie 
>>> , Mandy Chung , Mark 
>>> Reinhold , Paul Sandoz , 
>>> "A. Sundararajan" 
>>> 
>>> This is a review request for the changes for JEP 220: Modular Run-Time 
>>> Images [1].
>>> 
>>> There are a number of individuals responsible for these changes. Some, 
>>> possibly not all, are explicitly listed in the 'To' section of this mail, 
>>> and they will help address any comments arising from this review request.
>>> 
>>> The new run-time image structure is defined in JEP 220 [1], and can be seen 
>>> as a result of building the staging forest [2], or in the early access 
>>> builds [3].
>>> 
>>> Webrevs:
>>>   http://cr.openjdk.java.net/~chegar/8061971/00/
>>> 
>>> Due to the significant impact of these changes, a JDK 9 promotion has been 
>>> tentatively reserved for their integration. All comments are welcome, 
>>> although given the nature of the changes then we might have to create 
>>> separate issues in JIRA to address some of them later in jdk9/dev.
>>> 
>>> -Chris.
>>> 
>>> [1] http://openjdk.java.net/jeps/220
>>> [2] http://hg.openjdk.java.net/jigsaw/m2/
>>> [3] http://openjdk.java.net/projects/jigsaw/ea
>> 

Re: RFR [JEP 220] Modular Run-Time Images

[Sean Mullan]

The JDK security related changes look fine to me. The 
test/java/net/URLPermission/policy.* files only have copyright changes 
for some reason.


--Sean


On 11/20/2014 04:41 PM, Chris Hegarty wrote:



From: Chris Hegarty 
Subject: RFR [JEP 220] Modular Run-Time Images
Date: 20 November 2014 21:39:14 GMT
To: jigsaw-dev , jdk9-dev , build-dev , Alan Bateman , 
Alex Buckley , Chris Hegarty , Erik Joelsson , Jonathan Gibbons 
, Karen Kinnear , "Jim Laskey (Oracle)" , Magnus Ihse Bursie 
, Mandy Chung , Mark Reinhold , Paul Sandoz , "A. 
Sundararajan" 

This is a review request for the changes for JEP 220: Modular Run-Time Images 
[1].

There are a number of individuals responsible for these changes. Some, possibly 
not all, are explicitly listed in the 'To' section of this mail, and they will 
help address any comments arising from this review request.

The new run-time image structure is defined in JEP 220 [1], and can be seen as 
a result of building the staging forest [2], or in the early access builds [3].

Webrevs:
   http://cr.openjdk.java.net/~chegar/8061971/00/

Due to the significant impact of these changes, a JDK 9 promotion has been 
tentatively reserved for their integration. All comments are welcome, although 
given the nature of the changes then we might have to create separate issues in 
JIRA to address some of them later in jdk9/dev.

-Chris.

[1] http://openjdk.java.net/jeps/220
[2] http://hg.openjdk.java.net/jigsaw/m2/
[3] http://openjdk.java.net/projects/jigsaw/ea

Re: RFR [JEP 220] Modular Run-Time Images

[Daniel Fuchs]

Hi Chris,

I had a look at the changes in java.logging and java.management modules
(+ corresponding tests) and they look reasonable to me.

I also had a cursory look at the jdeps changes. It's difficult for me
to review that without importing the changes and playing with the
tool as this is a part I'm less familiar with - but I didn't see
anything that would be obviously wrong.

I skipped most of the rest (especially the build changes ;-)).

best regards,

-- daniel

On 20/11/14 22:41, Chris Hegarty wrote:



From: Chris Hegarty 
Subject: RFR [JEP 220] Modular Run-Time Images
Date: 20 November 2014 21:39:14 GMT
To: jigsaw-dev , jdk9-dev , build-dev , Alan Bateman , 
Alex Buckley , Chris Hegarty , Erik Joelsson , Jonathan Gibbons 
, Karen Kinnear , "Jim Laskey (Oracle)" , Magnus Ihse Bursie 
, Mandy Chung , Mark Reinhold , Paul Sandoz , "A. 
Sundararajan" 

This is a review request for the changes for JEP 220: Modular Run-Time Images 
[1].

There are a number of individuals responsible for these changes. Some, possibly 
not all, are explicitly listed in the 'To' section of this mail, and they will 
help address any comments arising from this review request.

The new run-time image structure is defined in JEP 220 [1], and can be seen as 
a result of building the staging forest [2], or in the early access builds [3].

Webrevs:
   http://cr.openjdk.java.net/~chegar/8061971/00/

Due to the significant impact of these changes, a JDK 9 promotion has been 
tentatively reserved for their integration. All comments are welcome, although 
given the nature of the changes then we might have to create separate issues in 
JIRA to address some of them later in jdk9/dev.

-Chris.

[1] http://openjdk.java.net/jeps/220
[2] http://hg.openjdk.java.net/jigsaw/m2/
[3] http://openjdk.java.net/projects/jigsaw/ea

Re: RFR [JEP 220] Modular Run-Time Images

[Alan Bateman]

On 21/11/2014 13:58, Seán Coffey wrote:

Chris,

just a passing comment from me. I've been looking at the extension 
directory changes. Looks like some code, locale resource files, man 
pages and help menus still need updating to remove the ext dir 
references. Is that tracked already ?


The rmic, javadoc and javac tools still have the concept of an 
extension directory.
Yes, there is a bit of clean-up required, particularly docs/man pages, 
and there is an issue tracking that.


For javac then we have JDK-8062015 to track looking at -endorseddirs as 
the changes mean it's only applicable when compiling to an target <= 8. 
Jon can confirm but I think that will be sorted out later.


-Alan.

Re: RFR [JEP 220] Modular Run-Time Images

[Seán Coffey]

Chris,

just a passing comment from me. I've been looking at the extension 
directory changes. Looks like some code, locale resource files, man 
pages and help menus still need updating to remove the ext dir 
references. Is that tracked already ?


The rmic, javadoc and javac tools still have the concept of an extension 
directory.


e.g.
http://hg.openjdk.java.net/jigsaw/m2/jdk/file/tip/src/jdk.rmic/share/classes/sun/rmi/rmic/newrmic/Main.java#l305
http://hg.openjdk.java.net/jigsaw/m2/langtools/file/tip/src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ToolOption.java#l70
http://hg.openjdk.java.net/jigsaw/m2/langtools/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java#l187
http://hg.openjdk.java.net/jigsaw/m2/jdk/file/tip/src/linux/doc/man/ja/javac.1

Hope that's expected.

regards,
Sean.

On 20/11/14 21:41, Chris Hegarty wrote:

From: Chris Hegarty 
Subject: RFR [JEP 220] Modular Run-Time Images
Date: 20 November 2014 21:39:14 GMT
To: jigsaw-dev , jdk9-dev , build-dev , Alan Bateman , 
Alex Buckley , Chris Hegarty , Erik Joelsson , Jonathan Gibbons 
, Karen Kinnear , "Jim Laskey (Oracle)" , Magnus Ihse Bursie 
, Mandy Chung , Mark Reinhold , Paul Sandoz , "A. 
Sundararajan" 

This is a review request for the changes for JEP 220: Modular Run-Time Images 
[1].

There are a number of individuals responsible for these changes. Some, possibly 
not all, are explicitly listed in the 'To' section of this mail, and they will 
help address any comments arising from this review request.

The new run-time image structure is defined in JEP 220 [1], and can be seen as 
a result of building the staging forest [2], or in the early access builds [3].

Webrevs:
   http://cr.openjdk.java.net/~chegar/8061971/00/

Due to the significant impact of these changes, a JDK 9 promotion has been 
tentatively reserved for their integration. All comments are welcome, although 
given the nature of the changes then we might have to create separate issues in 
JIRA to address some of them later in jdk9/dev.

-Chris.

[1] http://openjdk.java.net/jeps/220
[2] http://hg.openjdk.java.net/jigsaw/m2/
[3] http://openjdk.java.net/projects/jigsaw/ea