Re: RFR: JDK-8200132: Remove jre images and bundles

[Magnus Ihse Bursie]

Build change itself looks good to me. I think this solves the problem for the 
time being, even if the cleanup is not as complete. 

For JDK 12, we should see if we can go further. 

/Magnus

> 4 juni 2018 kl. 23:22 skrev Erik Joelsson :
> 
> Given the feedback, I have revised the patch to restore the ability to 
> produce a legacy jre image, but it is still removed from the default 
> "product-images" and "images" targets. To build it you need to specify it 
> explicitly as "legacy-jre-image" (or mac-legacy-jre-bundle for the macosx 
> specific image layout). I still removed the bundle targets for the jre image 
> as I very much doubt anyone except Oracle was using them anyway. In addition 
> to this, I also updated the help text a bit to reflect these changes.
> 
> Will this be good enough for those that still need a JRE image?
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.02/index.html
> 
> /Erik
> 
> 
>> On 2018-06-01 15:02, Erik Joelsson wrote:
>> Since JDK 9 and modules, the idea of a prebuilt JRE is no longer providing 
>> much value. The idea is rather that you link together an image with the 
>> modules and settings you actually need, either with or without your 
>> application. For this reason oracle will no longer ship JRE images that 
>> differ content wise to the JDK image in JDK 11 and we would like to remove 
>> them from the OpenJDK build to reduce complexity.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200132
>> 
>> Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.01/
>> 
>> /Erik
> 

Re: RFR: JDK-8200132: Remove jre images and bundles

[Martijn Verburg]

Thanks Erik,

We do have quite a few requests to build that jRE for AdoptOpenJDK
binaries, and this should let us continue doing that.

Cheers,
Martijn

On 5 June 2018 at 09:41, Alan Bateman  wrote:

> On 04/06/2018 22:22, Erik Joelsson wrote:
>
>> Given the feedback, I have revised the patch to restore the ability to
>> produce a legacy jre image, but it is still removed from the default
>> "product-images" and "images" targets. To build it you need to specify it
>> explicitly as "legacy-jre-image" (or mac-legacy-jre-bundle for the macosx
>> specific image layout). I still removed the bundle targets for the jre
>> image as I very much doubt anyone except Oracle was using them anyway. In
>> addition to this, I also updated the help text a bit to reflect these
>> changes.
>>
>> Will this be good enough for those that still need a JRE image?
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.02/index.html
>>
> This looks okay to me, and seems better than the configure option
> mentioned in one of the mails.
>
> I think you will still need to do some communication about this change,
> maybe to jdk-dev so that folks that may be relying on the jre image know
> that they need to build the legacy-jre-image target.
>
> I suspect this area of the build will be re-visited again if the Java
> Packager JEP goes ahead as that will need a similar list of modules and
> maybe options.
>
> -Alan.
>

Re: RFR: JDK-8200132: Remove jre images and bundles

[Alan Bateman]

On 04/06/2018 22:22, Erik Joelsson wrote:
Given the feedback, I have revised the patch to restore the ability to 
produce a legacy jre image, but it is still removed from the default 
"product-images" and "images" targets. To build it you need to specify 
it explicitly as "legacy-jre-image" (or mac-legacy-jre-bundle for the 
macosx specific image layout). I still removed the bundle targets for 
the jre image as I very much doubt anyone except Oracle was using them 
anyway. In addition to this, I also updated the help text a bit to 
reflect these changes.


Will this be good enough for those that still need a JRE image?

Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.02/index.html
This looks okay to me, and seems better than the configure option 
mentioned in one of the mails.


I think you will still need to do some communication about this change, 
maybe to jdk-dev so that folks that may be relying on the jre image know 
that they need to build the legacy-jre-image target.


I suspect this area of the build will be re-visited again if the Java 
Packager JEP goes ahead as that will need a similar list of modules and 
maybe options.


-Alan.

Re: RFR: JDK-8200132: Remove jre images and bundles

[Alan Bateman]

On 04/06/2018 21:40, Bob Vandette wrote:

:
I could live with a jlink option to create a JRE.  The problem is that the list 
of modules required to produce a
compatible JRE is not documented anywhere.  I tried fishing the list out of the 
build makefile but it’s not trivial.  I ended
up running “jimage list module | grep Module: on a JDK 10 JRE to get the list.

The `release` file in the top-level directory has a `MODULES` key with 
the complete list. Alternatively, `java --list-modules`.


In addition, there are other options used and it might that we should 
have the build invoke `jlink` with `--save-opts` so that the options are 
saved. Part of the original motive for `--save-opts` was to support a 
way to "relink" to re-run the link with the same options but pick up 
newer versions of the modules.


-Alan

Re: RFR: JDK-8200132: Remove jre images and bundles

[Erik Joelsson]

Given the feedback, I have revised the patch to restore the ability to 
produce a legacy jre image, but it is still removed from the default 
"product-images" and "images" targets. To build it you need to specify 
it explicitly as "legacy-jre-image" (or mac-legacy-jre-bundle for the 
macosx specific image layout). I still removed the bundle targets for 
the jre image as I very much doubt anyone except Oracle was using them 
anyway. In addition to this, I also updated the help text a bit to 
reflect these changes.


Will this be good enough for those that still need a JRE image?

Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.02/index.html

/Erik


On 2018-06-01 15:02, Erik Joelsson wrote:
Since JDK 9 and modules, the idea of a prebuilt JRE is no longer 
providing much value. The idea is rather that you link together an 
image with the modules and settings you actually need, either with or 
without your application. For this reason oracle will no longer ship 
JRE images that differ content wise to the JDK image in JDK 11 and we 
would like to remove them from the OpenJDK build to reduce complexity.


Bug: https://bugs.openjdk.java.net/browse/JDK-8200132

Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.01/

/Erik

Re: RFR: JDK-8200132: Remove jre images and bundles

[Bob Vandette]

> On Jun 4, 2018, at 4:32 PM, Jonathan Gibbons  
> wrote:
> 
> 
> 
> On 06/02/2018 12:20 AM, Alan Bateman wrote:
>> On 02/06/2018 08:05, Aleksey Shipilev wrote:
>>> :
>>> Unfortunately, in the age of containers, distribution size matters. It 
>>> makes the whole sense to ship
>>> JRE in Docker containers to provide the execution environment for the upper 
>>> layers. Remember, hardly
>>> any application is fully modularized and/or uses jlink/jimage way of 
>>> distribution.
>>> 
>>> Also, products that ship with their own OpenJDK distribution (e.g. 
>>> JetBrains IDEs) do ship with
>>> jres, which cuts down their distribution sizes.
>>> 
>>> Cost savings for having JRE only are significant, as can be observed with 
>>> current bundles:
>>> 
>>>  178M Jun  2 08:53 jdk-11-internal+0_linux-x64_bin.tar.gz
>>>   38M Jun  2 08:53 jre-11-internal+0_linux-x64_bin.tar.gz
>>> 
>>> Therefore, I believe removing jre is too disruptive, at least for 11, at 
>>> least until we see that the
>>> whole jlink/jimage thing really works out in the wider Java ecosystem and 
>>> JREs are really abandoned.
>> I don't disagree with the significance of what has been proposed here. 
>> However, just to point out that creating what used to know as the JRE is one 
>> `jlink` command. There is no requirement for the application or libraries 
>> using that run-time be developed as modules. Also incorporate generating of 
>> JDK run-time images into the build when working with containers is very 
>> useful as you get fine control on which modules to include.
>> 
>> -Alan
>> 
> 
> If it is that easy to generate a JRE image, why not provide a target to 
> create such an image, that invokes that one command?  The target need not be 
> part of the default build, but would be available for those that want to 
> build it.

I could live with a jlink option to create a JRE.  The problem is that the list 
of modules required to produce a
compatible JRE is not documented anywhere.  I tried fishing the list out of the 
build makefile but it’s not trivial.  I ended
up running “jimage list module | grep Module: on a JDK 10 JRE to get the list.

Bob.


> 
> -- Jon

Re: RFR: JDK-8200132: Remove jre images and bundles

[Jonathan Gibbons]

On 06/02/2018 12:20 AM, Alan Bateman wrote:

On 02/06/2018 08:05, Aleksey Shipilev wrote:

:
Unfortunately, in the age of containers, distribution size matters. 
It makes the whole sense to ship
JRE in Docker containers to provide the execution environment for the 
upper layers. Remember, hardly
any application is fully modularized and/or uses jlink/jimage way of 
distribution.


Also, products that ship with their own OpenJDK distribution (e.g. 
JetBrains IDEs) do ship with

jres, which cuts down their distribution sizes.

Cost savings for having JRE only are significant, as can be observed 
with current bundles:


  178M Jun  2 08:53 jdk-11-internal+0_linux-x64_bin.tar.gz
   38M Jun  2 08:53 jre-11-internal+0_linux-x64_bin.tar.gz

Therefore, I believe removing jre is too disruptive, at least for 11, 
at least until we see that the
whole jlink/jimage thing really works out in the wider Java ecosystem 
and JREs are really abandoned.
I don't disagree with the significance of what has been proposed here. 
However, just to point out that creating what used to know as the JRE 
is one `jlink` command. There is no requirement for the application or 
libraries using that run-time be developed as modules. Also 
incorporate generating of JDK run-time images into the build when 
working with containers is very useful as you get fine control on 
which modules to include.


-Alan



If it is that easy to generate a JRE image, why not provide a target to 
create such an image, that invokes that one command?  The target need 
not be part of the default build, but would be available for those that 
want to build it.


-- Jon

Re: RFR: JDK-8200132: Remove jre images and bundles

[Alan Bateman]

On 04/06/2018 20:45, Bob Vandette wrote:
If we do this, shouldn’t we provide an aggregator module to allow 
developers to
easily create a Java runtime with the same list of modules?  AFAIK, 
this doesn’t exists.
The java.se  module is not the same.  It’s missing 
many modules.


That creates an attractive nuisance in that developers would end 
requiring it (with `requires) and it's not a "platform" or a module that 
someone should be depending on.  As I recall, that was part of the 
reason why the proposed "jdk.jre" aggregator was dropped during the JDK 
9 development. It may be something for the Packaging Tool (draft JEP 
JDK-8200758). I could imagine the build for the packaging tool 
generating a list of modules that the tool uses when creating packages 
for end-user applications.


-Alan

Re: RFR: JDK-8200132: Remove jre images and bundles

[Bob Vandette]

If we do this, shouldn’t we provide an aggregator module to allow developers to
easily create a Java runtime with the same list of modules?  AFAIK, this 
doesn’t exists.
The java.se  module is not the same.  It’s missing many 
modules.

Bob.


> On Jun 2, 2018, at 1:01 PM, Alan Bateman  wrote:
> 
> On 02/06/2018 15:07, Magnus Ihse Bursie wrote:
>> It is probably relatively trivial to add a configure option to select just 
>> the "JRE modules" when building, rather than all modules. If we add such an 
>> option, it would still be possible to build a traditional JRE, not just at 
>> the same time as building the full JDK. Doing Erik's change as suggested 
>> here, combined with such additional functionality would allow us to remove a 
>> lot of old cruft from the build system, while still allowing distributors to 
>> build a JRE. I'd recommend doing something like this, rather than to delay 
>> this patch to post-JDK11.
>> 
> Removing old cruft is good. Also not building the jre image by default might 
> reduce build times a little bit, a boon for those doing "make images" but 
> never using the jre image (as the tests are run on the jdk image, not the jre 
> image).
> 
> I don't have an opinion on whether configure option or a make target is the 
> right approach. It might be that those consuming the jre image today are 
> using the bundles target, a target that I wouldn't expect most developers 
> will use when working on OpenJDK. Part of the socializing of this topic might 
> be to get a better handle on what downstream projects and packagers are doing 
> with the jre image (beyond creating install bundles for specific distros).
> 
> -Alan

Re: RFR: JDK-8200132: Remove jre images and bundles

[Alan Bateman]

On 02/06/2018 15:07, Magnus Ihse Bursie wrote:

It is probably relatively trivial to add a configure option to select just the "JRE 
modules" when building, rather than all modules. If we add such an option, it would 
still be possible to build a traditional JRE, not just at the same time as building the 
full JDK. Doing Erik's change as suggested here, combined with such additional 
functionality would allow us to remove a lot of old cruft from the build system, while 
still allowing distributors to build a JRE. I'd recommend doing something like this, 
rather than to delay this patch to post-JDK11.

Removing old cruft is good. Also not building the jre image by default 
might reduce build times a little bit, a boon for those doing "make 
images" but never using the jre image (as the tests are run on the jdk 
image, not the jre image).


I don't have an opinion on whether configure option or a make target is 
the right approach. It might be that those consuming the jre image today 
are using the bundles target, a target that I wouldn't expect most 
developers will use when working on OpenJDK. Part of the socializing of 
this topic might be to get a better handle on what downstream projects 
and packagers are doing with the jre image (beyond creating install 
bundles for specific distros).


-Alan

Re: RFR: JDK-8200132: Remove jre images and bundles

[Scott Palmer]

I work on a product that is built from a collection of plugins. Many of the 
plugins are distributed after the main framework is installed. That product 
will always need a full JRE because there is no way to know in advance which 
modules will be needed.

A full JRE “image” is a requirement for me.

Also, jlink apparently only works with 100% modular applications. That will be 
impossible in the near term as all dependencies are not yet modularized and 
they may never be.

Modularization has been very disruptive. We have yet to move past Java 8 
because code doesn’t “just work” when transitioning from Java 8 to anything 
beyond. With previous upgrades we only had to deal with minor issues, if any.

Scott

> On Jun 2, 2018, at 3:05 AM, Aleksey Shipilev  wrote:
> 
> Therefore, I believe removing jre is too disruptive, at least for 11, at 
> least until we see that the
> whole jlink/jimage thing really works out in the wider Java ecosystem and 
> JREs are really abandoned.
> 
> Thanks,
> -Aleksey
> 

Re: RFR: JDK-8200132: Remove jre images and bundles

[Magnus Ihse Bursie]

It is probably relatively trivial to add a configure option to select just the 
"JRE modules" when building, rather than all modules. If we add such an option, 
it would still be possible to build a traditional JRE, not just at the same 
time as building the full JDK. Doing Erik's change as suggested here, combined 
with such additional functionality would allow us to remove a lot of old cruft 
from the build system, while still allowing distributors to build a JRE. I'd 
recommend doing something like this, rather than to delay this patch to 
post-JDK11. 

/Magnus

> 2 juni 2018 kl. 10:20 skrev Alan Bateman :
> 
>> On 02/06/2018 08:05, Aleksey Shipilev wrote:
>> :
>> Unfortunately, in the age of containers, distribution size matters. It makes 
>> the whole sense to ship
>> JRE in Docker containers to provide the execution environment for the upper 
>> layers. Remember, hardly
>> any application is fully modularized and/or uses jlink/jimage way of 
>> distribution.
>> 
>> Also, products that ship with their own OpenJDK distribution (e.g. JetBrains 
>> IDEs) do ship with
>> jres, which cuts down their distribution sizes.
>> 
>> Cost savings for having JRE only are significant, as can be observed with 
>> current bundles:
>> 
>>  178M Jun  2 08:53 jdk-11-internal+0_linux-x64_bin.tar.gz
>>   38M Jun  2 08:53 jre-11-internal+0_linux-x64_bin.tar.gz
>> 
>> Therefore, I believe removing jre is too disruptive, at least for 11, at 
>> least until we see that the
>> whole jlink/jimage thing really works out in the wider Java ecosystem and 
>> JREs are really abandoned.
> I don't disagree with the significance of what has been proposed here. 
> However, just to point out that creating what used to know as the JRE is one 
> `jlink` command. There is no requirement for the application or libraries 
> using that run-time be developed as modules. Also incorporate generating of 
> JDK run-time images into the build when working with containers is very 
> useful as you get fine control on which modules to include.
> 
> -Alan
> 

Re: RFR: JDK-8200132: Remove jre images and bundles

[Alan Bateman]

On 02/06/2018 08:05, Aleksey Shipilev wrote:

:
Unfortunately, in the age of containers, distribution size matters. It makes 
the whole sense to ship
JRE in Docker containers to provide the execution environment for the upper 
layers. Remember, hardly
any application is fully modularized and/or uses jlink/jimage way of 
distribution.

Also, products that ship with their own OpenJDK distribution (e.g. JetBrains 
IDEs) do ship with
jres, which cuts down their distribution sizes.

Cost savings for having JRE only are significant, as can be observed with 
current bundles:

  178M Jun  2 08:53 jdk-11-internal+0_linux-x64_bin.tar.gz
   38M Jun  2 08:53 jre-11-internal+0_linux-x64_bin.tar.gz

Therefore, I believe removing jre is too disruptive, at least for 11, at least 
until we see that the
whole jlink/jimage thing really works out in the wider Java ecosystem and JREs 
are really abandoned.
I don't disagree with the significance of what has been proposed here. 
However, just to point out that creating what used to know as the JRE is 
one `jlink` command. There is no requirement for the application or 
libraries using that run-time be developed as modules. Also incorporate 
generating of JDK run-time images into the build when working with 
containers is very useful as you get fine control on which modules to 
include.


-Alan

Re: RFR: JDK-8200132: Remove jre images and bundles

[Alan Bateman]

On 01/06/2018 23:02, Erik Joelsson wrote:
Since JDK 9 and modules, the idea of a prebuilt JRE is no longer 
providing much value. The idea is rather that you link together an 
image with the modules and settings you actually need, either with or 
without your application. For this reason oracle will no longer ship 
JRE images that differ content wise to the JDK image in JDK 11 and we 
would like to remove them from the OpenJDK build to reduce complexity.


Bug: https://bugs.openjdk.java.net/browse/JDK-8200132

Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.01/
You are right that moving to modules has blurred the historical 
distinction between what we used to know as the JDK and JRE and I 
completely agree that the JRE is now a relic and just not interesting 
since JDK 9. However, dropping the ability to build the "jre" image is a 
significant change and I think will need to be socialized more widely as 
it will likely impact downstream installers and other consumers of the 
build. It may even need a JEP.


-Alan

Re: RFR: JDK-8200132: Remove jre images and bundles

[Aleksey Shipilev]

On 06/02/2018 08:36 AM, Magnus Ihse Bursie wrote:
> The actual changes look good to me.
> 
> As a follow up, I think we should check if we could remove some of the JDK 
> prefixes that was in
> place just to differentiate from the JRE. The term JDK is so overloaded, so 
> it would be good to
> get rid of it where possible (as in "JDK image", which should be only "image" 
> now).
> 
> I also hear Martin's fear about this being a too large change. I don't think 
> that is a problem
> per se, but you should probably get some input from our downstream 
> distributors so that they are
> able to provide the packages they feel are needed.

Unfortunately, in the age of containers, distribution size matters. It makes 
the whole sense to ship
JRE in Docker containers to provide the execution environment for the upper 
layers. Remember, hardly
any application is fully modularized and/or uses jlink/jimage way of 
distribution.

Also, products that ship with their own OpenJDK distribution (e.g. JetBrains 
IDEs) do ship with
jres, which cuts down their distribution sizes.

Cost savings for having JRE only are significant, as can be observed with 
current bundles:

 178M Jun  2 08:53 jdk-11-internal+0_linux-x64_bin.tar.gz
  38M Jun  2 08:53 jre-11-internal+0_linux-x64_bin.tar.gz

Therefore, I believe removing jre is too disruptive, at least for 11, at least 
until we see that the
whole jlink/jimage thing really works out in the wider Java ecosystem and JREs 
are really abandoned.

Thanks,
-Aleksey

Re: RFR: JDK-8200132: Remove jre images and bundles

[Magnus Ihse Bursie]

The actual changes look good to me. 

As a follow up, I think we should check if we could remove some of the JDK 
prefixes that was in place just to differentiate from the JRE. The term JDK is 
so overloaded, so it would be good to get rid of it where possible (as in "JDK 
image", which should be only "image" now). 

I also hear Martin's fear about this being a too large change. I don't think 
that is a problem per se, but you should probably get some input from our 
downstream distributors so that they are able to provide the packages they feel 
are needed. 

/Magnus

> 2 juni 2018 kl. 01:02 skrev Erik Joelsson :
> 
> Since JDK 9 and modules, the idea of a prebuilt JRE is no longer providing 
> much value. The idea is rather that you link together an image with the 
> modules and settings you actually need, either with or without your 
> application. For this reason oracle will no longer ship JRE images that 
> differ content wise to the JDK image in JDK 11 and we would like to remove 
> them from the OpenJDK build to reduce complexity.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200132
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.01/
> 
> /Erik
> 

Re: RFR: JDK-8200132: Remove jre images and bundles

[Martin Buchholz]

JREs are a very long tradition.  I suggest deferring disruptive changes
like this to some release past jdk11.

On Fri, Jun 1, 2018 at 3:02 PM, Erik Joelsson 
wrote:

> Since JDK 9 and modules, the idea of a prebuilt JRE is no longer providing
> much value. The idea is rather that you link together an image with the
> modules and settings you actually need, either with or without your
> application. For this reason oracle will no longer ship JRE images that
> differ content wise to the JDK image in JDK 11 and we would like to remove
> them from the OpenJDK build to reduce complexity.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200132
>
> Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.01/
>
> /Erik
>
>

Re: RFR: JDK-8200132: Remove jre images and bundles

[mandy chung]

Looks good.  The build is much simplified.

Modules.gmk
  include_in_jdk can be removed since it should always be true.
  In fact build.properties support can be removed some day.

Mandy

On 6/1/18 3:02 PM, Erik Joelsson wrote:
Since JDK 9 and modules, the idea of a prebuilt JRE is no longer 
providing much value. The idea is rather that you link together an image 
with the modules and settings you actually need, either with or without 
your application. For this reason oracle will no longer ship JRE images 
that differ content wise to the JDK image in JDK 11 and we would like to 
remove them from the OpenJDK build to reduce complexity.


Bug: https://bugs.openjdk.java.net/browse/JDK-8200132

Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.01/

/Erik

RFR: JDK-8200132: Remove jre images and bundles

[Erik Joelsson]

Since JDK 9 and modules, the idea of a prebuilt JRE is no longer 
providing much value. The idea is rather that you link together an image 
with the modules and settings you actually need, either with or without 
your application. For this reason oracle will no longer ship JRE images 
that differ content wise to the JDK image in JDK 11 and we would like to 
remove them from the OpenJDK build to reduce complexity.


Bug: https://bugs.openjdk.java.net/browse/JDK-8200132

Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.01/

/Erik