[External] : Re: jmods-less jlinking prototype

[Ron Pressler]

> On 15 Mar 2023, at 10:42, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> 

> Reducing JDK's size is important and would in our opinion be worth some
> extra complexity in jlink code. Why?
> 
>   1. Allow recursive jlink runs (see above).

I understand it’s an added capability. I’d like to understand why it’s important.

>   2. Installed JDK size is something everyone is paying a tax for,
>      even though they might not even use jlink for their application
>      needs.

But if they don’t use jlink, the easier solution is to just delete the jmod files.

> For example installing the *full* JDK on Fedora or Red Hat
>      Enterprise Linux by picking the 'java-17-openjdk-jmods' package,
>      would have users download a whopping extra ~230MB of data.

If size is that important you can get an even bigger reduction by not including debug info.

>   3. Considering a cloud setup where a full JDK container image is
>      being used to generate an application specific image including
>      the Java runtime, such a JDK container image would have to
>      include the jmods archives. The full JDK container image is an
>      infrastructure component in such a setup. Even a ~80MB extra for
>      such images results in extra money needing to be spent (for
>      storage or network bandwidth).

I still don’t understand. How many containers are used for building?
Assuming a nice JDK build where jmods are 25%, we’re talking about a 25% difference in the bandwidth and storage for the *build* infra.
How big of an impact is it?

I think THIS is the main motivation here, and so more data about the impact is what’s required to assess the importance of the proposal.


> What's more, the size difference
>      makes using the same JDK image for application runtime - yes some
>      users want the full JDK in containers - as well as for the build-
>      your-own-application-image jlink use-case uncompelling.
> 

This one is really confusing to me. If you’re concerned with runtime size, with jlink you can reduce the size to 40MB in total; that’s a much, much bigger impact than removing the jmod files.
So if size is important, jlink has a far bigger positive impact than a negative one, and a bigger positive impact than what you’re proposing — running jlink reduces the size by 85% as opposed to 25% —
and if you don’t want to use jlink you can just delete the jmod files and be done with it. 

I understand that what you’re saying is that with a bit more complexity you can get the best of both worlds. It’s just that without more information about the impact, it’s unclear how significantly are both worlds better than just one world.

— Ron