Smaller JDK base image using Java 11 modularity (jlink) #181
Comments
|
I think it'll be hard to define meaningful ready-made subsets, likely it will always be too little or too much for chosen applications. The modules to include should be determined by the specific build itself. In the example I built I used a hard-coded list I head determined upfront, but this can easily be automated by running the jdeps tool against all the JARs to be included: The reason why I didn't do it is that jdeps works with JARs as input, i.e. it can only be run after the application JAR has been created. So this won't benefit from caching, if the application changes, also if the change doesn't lead to the inclusion of more modules. |
|
From @gunnarmorling comment over in #160 (which I want to keep focused on Java 11 itself):
This could be looked more into here and discussed with our OpenJDK friends when this gets picked up. |
|
@gunnarmorling following up on a possible first step in the direction of this issue, and based on your comments on the original Java 11 PR over here re. |
but do not install it on Java 8
|
#198 just merged, but that's just the basic pre-req, there is more work here how to actually use this... #198 has a very nice simple standalone example how to use Perhaps https://maven.apache.org/plugins/maven-jlink-plugin/ could be of use for this as well? |
This reverts commit b9a5430. This seemed to very significantly bloat the size of the image: 489 MB on hub.docker.com, 777 MB on local docker; as opposed to 448 MB locally and ca. 160-ish MB (?) on Hub without this. So let's park this, until we pick up the overall #181 idea, and https://bugzilla.redhat.com/show_bug.cgi?id=1652177 is solved. Until then, users of this image could technically still manually build their own image FROM this one, and just add this: RUN yum -y install java-11-openjdk-jmods
|
Actually to prepare #203, I just reverted the #198 again; with this, latest-java11 is down from 489 MB to 166 MB. |
once and after we'll have #160, then I think the idea also in raised #180 by @gunnarmorling re. a modular small JDK base image (
jlink) is worth a dedicated issue ... let's discuss this further and some day implement under this issue? -- One of the points to IMHO clarify is:Could we just settle on a suitable list of JDK modules to hard code into the Java S2I base image (e.g. like what @gunnarmorling has done over here) ? Like obviously no UI stuff, and ditch really old and in practice un-used modules in modern server side containerized Java apps.
Or is this an illusion and there would have to have some (complicated...) mechanism to chose modules, and have a multi-stage build, for JDK and application? (Urgh, with S2I.)
May be a middle way and a (hopefully small) set of pre-baked S2I Java 11 image types with different JDK modules?
The text was updated successfully, but these errors were encountered: