Thanks for the patching idea, Remi. I'll try that. > So while it might be desirable to expose the interface for plugins, I think it will need further exploration to see if it makes sense or not.
Understood, it's just that in the current form I don't think many people (outside of the JDK) will ever try it out and give feedback. Having a public incubating API might help with that. In terms of use cases I was thinking of generating annotation indexes and adding them to the image, removing unused code or applying byte code enhancements e.g. for Hibernate entities. Currently, plug-ins for the specific build system are used in such cases (e.g. Maven/Gradle plug-ins), but providing this functionality via generally usable jlink plug-ins would be awesome. 2017-11-21 10:29 GMT+01:00 Remi Forax <fo...@univ-mlv.fr>: > Hi Alan, > I use jlink plugins for 2 things, > - code generation, i.e. find patterns in the bytecode and optimize them > because at link time you are in a closed world, so something that was > dynamic is not anymore. > - just bytecode crawling to find specific annotations to improve startup. > > I believe implementation like Weld or Spring should have access to an open > API to be able to do thing kind of optimizations, imagine, you could create > all proxies upfront or better use invokedynamic to even avoid proxy > creation at all. > > The plugin API doesn't have to be complex, it's a read/replace/append of > bytecode files. > > Rémi > > ----- Mail original ----- > > De: "Alan Bateman" <alan.bate...@oracle.com> > > À: "Gunnar Morling" <gun...@hibernate.org> > > Cc: "jigsaw-dev" <jigsaw-dev@openjdk.java.net> > > Envoyé: Mardi 21 Novembre 2017 09:33:33 > > Objet: Re: Resolution exception when service interface gets exposed via > --add-exports > > > On 20/11/2017 21:56, Gunnar Morling wrote: > >> I see, thanks for the clarification. > >> > >> It's a pity, though, I hoped to employ that approach for providing a > >> custom jlink plug-in (implementation of > >> jdk.tools.jlink.plugin.Plugin). So it seems that's not possible until > >> jdk.jlink exports j.t.j.plugin? Are there any plans to do so some time > >> soon? > >> > >> Even if it was marked as experimental/incubating, being able to > >> provide custom jlink plug-ins would enable interesting use cases. > >> > > There was interest in creating an incubating module in JDK 9 but it was > > put aside due to the issues of tool modules depending on an incubating > > module. The other issue is that most of the interesting plugins to date > > do code generation at link time and are deeply tied to specific areas of > > java.base and other core modules (they can't really live outside of the > > jdk repo). So while it might be desirable to expose the interface for > > plugins, I think it will need further exploration to see if it makes > > sense or not. > > > > -Alan >
