Making jlink Plug-in API public

[Gunnar Morling]

Am Mo., 28. Dez. 2020 um 10:00 Uhr schrieb Alan Bateman <
Alan.Bateman at oracle.com>:

> On 25/12/2020 10:29, Gunnar Morling wrote:
> > Hi all,
> >
> > Are there any plans for making the jlink Plug-in API public any time
> soon,
> > perhaps for JDK 17?
> >
> > I think the ability to implement custom plug-ins that are run at linking
> > time would open up quite a few interesting opportunities, e.g.
> >
> > - removing unused members and obfuscation
> > - adding resources like annotation indexes for the whole image
> > - verifying that exported and required API methods match (avoiding
> > NoSuchMethodErrors due to adding incompatible module versions to an
> image)
> >
> > The latter would be interesting in particular for monolithic applications
> > built jointly by multiple teams, avoiding the need to recompile the
> entire
> > application if only a single module changed, while still having fidelity
> > that APIs would match.
> >
> The intention in early revisions of JEP 282 was to expose a plugin API.
> It went through many iterations and re-designs during JDK 9 but it
> didn't get to the point where it was really ready to be exposed by an
> incubator module. There was also a complication at the time with
> incubator modules providing implementations of ToolProvider (that issue
> has since been resolved as it became a blocker for jpackage too).
>
> Is it worth giving it a priority boost and re-examine it now? Hard to
> say as it would likely require several iterations and a lot of review
> cycles to bring this to incubation stage.


That's interesting; what is missing from your PoV to make the API an
incubating one?


> At the same time, our
> experience with plugins to date is that many of the plugins are deeply
> tied to core modules and just aren't maintainable outside of the jdk
> repo.


That's fair. OTOH, right now it's really cumbersome for external
contributors to explore the area, as the plug-in API is not exposed and
it's not trivial to have jlink pick up custom plug-ins. I'm not aware of
any external plug-in really.


> I think it could also be argued that some of the suggestions that
> you list should be be plugins included in the jdk.jlink module. For
> example indexing of annotations was something that was explored and
> prototyped at one point (the original requirements document for the
> module system JSR had an item along these lines). A tool that scans a
> module path to do static analysis and detect incompatibilities could be
> valuable as a link time plugin. Are these plugins that you would be
> interested in developing, contributing, and maintaining?
>

I could see myself contributing to a plug-in around signature validation,
depending on how involved that task would be. I did a quick PoC and discuss
it here:


https://www.morling.dev/blog/jlinks-missing-link-api-signature-validation/

This is using the existing Animal Sniffer tool for a basic signature check.
I'm not sure how much effort it'd be to fully implement this, and also
catch things like added non-virtual methods in a base class/interface,
changes to type parameters, and more. Could existing code from the JDK be
re-used for that task?

Thanks,

--Gunnar


-Alan.
>