how to split up runtime (original) (raw)

how to split up runtime / development parts in OpenJDK 11?

Alan Bateman 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 https://launchpad.net/~openjdk-r/+archive/ubuntu/ppa/+build/15097262 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.

-Alan

More information about the jdk-dev mailing list