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

[Alan Bateman]

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