[Proposal] jlink plugin which replaces dynamic shared libraries

[Severin Gehwolf]

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