[Proposal] jlink plugin which replaces dynamic shared libraries
Severin Gehwolf
sgehwolf at redhat.com
Tue Dec 4 13:52:07 UTC 2018
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
More information about the jigsaw-dev
mailing list