Re: Making jlink Plug-in API public

[Alan Bateman]

On 29/12/2020 19:29, Gunnar Morling wrote:

:

That's interesting; what is missing from your PoV to make the API an 
incubating one?
Getting consensus that it's the right thing to do, and then the 
commitment to doing it. The latter requires re-examining the internal 
plugin API, looking at the issues that have come up since JDK 9, going 
over each of the API elements, iteration, and then setting it on a 
course to incubate for a release or two, gathering feedback, then 
eventually make it permanent and maintaining it. On one hard, it could 
be interesting to have an eco system of useful link-time plugins.. On 
the other hand, I think many of the plugins will be tied to core modules 
so cannot be maintained outside of the jdk repo. Also many of the 
plugins that we have experience with to date involve generating classes 
or modifying existing class files at link time so there may be an 
argument to wait until the JDK has a bytecode API.




:

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?
Nice blog and PoC! Yes, I think this is worth exploring more as static 
analysis to detect mismatch with compile-time could be useful. A 
possible starting point is something that scans a module path, it 
doesn't have to start out as a jlink plugin. I could imagine `java 
--validate-modules` making use of this to do deep analysis for example.


-Alan

Re: Making jlink Plug-in API public

[Gunnar Morling]

Am Mo., 28. Dez. 2020 um 10:00 Uhr schrieb Alan Bateman <
alan.bate...@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.
>

Re: Making jlink Plug-in API public

[Alan Bateman]

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. 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. 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?


-Alan.