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