Hi, Apologies if this isn't the right list. Please let me know where jlink related issues are being discussed.
The Problem: ----------------------------------------------- This issue originally surfaced in our packaged OpenJDK 11 builds for Fedora. If a user created a custom image from the packaged JDK, the resulting custom image would be huge in size because of non-stripped debug symbols in the packaged binaries (~500MB vs. ~50MB). Native libraries and executables in the packaged JDK image would be properly stripped of debug symbols, but copies of those files in the jmod files would not be. That has to do with a) How we build for the Fedora distribution: --with-native-debug-symbols=internal configure switch. b) When the stripping happens. In the Fedora case, b) happens external to the OpenJDK build by the RPM build system *after* the OpenJDK build actually completes. This means copies of native libraries and executables with full debug symbols would already be "zipped up" in jmod files when the distribution build's stripping process starts. Hence, the distribution build system doesn't "see" DSO/EXE copies in jmod files in the JDK images directory. They are archived in jmod files. Because of this we end up with properly stripped libraries and executables in the default, extracted JDK image, but DSOs/EXEs in the 'jmods' directory would still have full debug symbols internal to the binaries. Yet, when jlink is being run, jmod files in directory 'jmods' are being used for creating custom modular JDK images. The original downstream issue is: https://bugzilla.redhat.com/show_bug.cgi?id=1652177 Proposed Solution: ----------------------------------------------- The solution we came up with is a new jlink plugin which - at runtime - replaces matching DSOs from jmod files with versions from the JDK image (or a JDK image of the same version pointed to by a property). As a result, properly stripped DSOs are being used for the custom JDK image and the size issue goes away. We are aware that this is a rather distribution specific use-case, but it might be useful for other downstream consumers (Debian?) too. That's why I'm proposing this here. Would there be interest in having this jlink plugin upstream? If so, I'd create a bug and will propose a formal RFR. webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/jlink-native-replace-plugin/webrev/ Thoughts? Thanks, Severin
