Resolution exception when service interface gets exposed via --add-exports

[Gunnar Morling]

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 <forax at 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.Bateman at oracle.com>
> > À: "Gunnar Morling" <gunnar at hibernate.org>
> > Cc: "jigsaw-dev" <jigsaw-dev at 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
>