Hi Alan, On Tue, 2018-12-04 at 13:19 +0000, Alan Bateman wrote: > On 04/12/2018 12:47, Severin Gehwolf wrote: > > : > > > > > > 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? > > > > If I read this correctly then it makes assumption that jlink is run on a > JDK build that matches exactly the build of the packaged modules on the > module path specified to the tool - is that right?
The inherent assumption is that jlink is run on a JDK build that has a module set at least equal to the modules specified to the tool. Other than that, yes. > If so then it will > work for the scenario you described but it won't work in general as the > builds may not match. Also it could never work when cross targeting, > e.g. using jlink on linux-x64 to create a run-time image for an embedded > linux-arm. Yes, understood. > You mail makes me wonder if it would be feasible to have a plugin that > does the stripping, maybe you've looked into that already? We've considered it, but I haven't looked into it. Thanks, Severin
