jmods-less jlinking prototype

[Severin Gehwolf]

Hi Ron,

On Wed, 2023-03-15 at 00:14 +0000, Ron Pressler wrote:
> > On 14 Mar 2023, at 10:36, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> > 
> > The Problem:
> > ------------
> > Why do we need the 'jmods' directory when running jlink when 'java --
> > list-modules' lists all the modules and all the files from the JDK
> > build are in <install/location/of/jdk> (only 'jmods' directory is
> > missing)[1]?
> 
> Hi.
> 
> The way that’s stated it looks like the problem you’re trying to
> solve is of a JDK tool that stops working when you delete some JDK
> files.

It's less of a question of wanting to delete some JDK files, but more
something we had to in order to not put off too many users by the size
change between JDK 8 and JDK 9+. I'm trying to explain some of it
below.

The footnote had another motivational point: Be able to recursively
jlink.

-----
[1] In the Leyden context there is also this issue:
 Let 'jlink' be the tool to "drive" condensor passes. Would I be
 able to use it recursively, minus after the final step? Not in it's
 current form without using '--keep-packaged-modules':
 $ ./images/jdk/bin/jlink --add-modules jdk.jlink --output build/test-jlink-image
 $ ./build/test-jlink-image/bin/jlink --add-modules java.base --output build/test-java.base-image
 Error: --module-path is not specified and this runtime image does not contain jmods directory.
 Usage: jlink <options> --module-path <modulepath> --add-modules <module>[,<module>...]
 Use --help for a list of possible options
-----

Note that --keep-packaged-modules isn't on by default and I'd argue
it's less compelling having to use it in the Leyden context because of
the mentioned size issue below. What if somebody wants to run a
condensor in a cloud setup? Is this not something we want to consider?

> Is the actual issue reducing the JDK’s size? If so, can you give some
> more motivation for why reducing the size — not of a runtime but of
> an SDK — by ~80 MB or 25% is something worth doing given that the
> solution is not entirely trivial?

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).
   2. Installed JDK size is something everyone is paying a tax for,
      even though they might not even use jlink for their application
      needs. 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.
      Network bandwidth and storage isn't free and this exacerbates in
      the cloud world with JDK container image sizes. Note that the
      size difference is different depending how the JDK itself is
      being built. Here is what I'm seeing for Fedora and Red Hat
      Enterprise Linux[1]:
      $ du -sh $(rpm -ql java-17-openjdk-jmods | head -n1)
      254M /usr/lib/jvm/java-17-openjdk-[...]/jmods
      So in our case it's not 25% but up to 55% of the entire JDK
      install. The reason for this is included debuginfo symbols in
      native libraries which get packaged up in jmods and won't get
      stripped by the build system because jmods are opaque artifacts.
   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). 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.


Thanks,
Severin

[1] See 'Size' in https://koji.fedoraproject.org/koji/rpminfo?rpmID=33327839