how to split up runtime / development parts in OpenJDK 11?
Alan.Bateman at oracle.com
Thu Jul 12 10:49:23 UTC 2018
On 12/07/2018 08:58, Matthias Klose wrote:
> yes, we end up with only one runtime package. I assume you could
> install openjdk from any Debian/Fedora/Suse/Ubuntu packages and see
> how this is packaged. Details may vary, but the schema should be clear.
> As an alternative, have a look at the build log available from
> At the end of the log, you'll find a summary of the binary packages
> built from this source package, both the meta data and the included
> files. Currently the lib/modules container files are found in the
> "-dev" packages.
The "Built files" link on this page doesn't list any -dev packages but
the jre-headless, jre, and jdk packages are enough to help the discussion.
In this build, the openjdk-11-jre-headless package seems to contain the
lib/modules file from the "jdk" run-time image. The jimage tool can be
used to list its contents and I can see that it contains the
classes/resources for tool modules such as jdk.compiler and jdk.jdi
(these modules are not included in the "jre" run-time image). One or two
tool modules have shared libraries and I see they are in
openjdk-11-jre-headless tool so at least these modules aren't completely
broken by the split. I can't quite tell where all the launchers are but
by stripping someone from the openjdk-11-jre-headless package it means
you have incomplete modules when only this package is installed.
I think the fundamental issue here is that run-time image format in JEP
220 does not lend itself to stripping and re-creation by way of
overlaying, at least not at the level of individual files in the
run-time image. You can of course work by diff'ing the content list of
the "jdk" and "jre" run-time images but it means you end up with modules
in the base package that are incomplete. I don't see a solution to this
that doesn't involve re-running jlink (as Martin and Erik pointed out)
or else significant changes to support multiple container files in the
same run-time image (which brings a lot of complexity). Maybe it is time
to move away from the jre- packages as they have been somewhat legacy
for several releases.
More information about the jdk-dev