RFR: JDK-8200132: Remove jre images and bundles
Jonathan Gibbons
jonathan.gibbons at oracle.com
Mon Jun 4 20:32:58 UTC 2018
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
More information about the build-dev
mailing list