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

[forax at univ-mlv.fr]

My opinion is that we should fix --patch-module to allow to patch the module-info.class, 
you always end up with this restriction once you use --patch-module. 

Rémi 

> De: "Gunnar Morling" <gunnar at hibernate.org>
> À: "Alan Bateman" <Alan.Bateman at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoyé: Mercredi 22 Novembre 2017 12:49:10
> Objet: Re: Resolution exception when service interface gets exposed via
> --add-exports

> Just in case others end up in the same situation: --patch-module (alone) doesn't
> do the trick as it can't be used to override the module-info.class of the
> jdk.jlink module. So I'm just using it to inject my plug-in and then use a Java
> Agent to register that one as a service provider (via
> Instrumentation#redefineModule()).
> If I find the time I'll try and blog about it; needless to say, that a public,
> supported API would be much appreciated :) Thanks Alan and Remi for your help!

> 2017-11-21 11:46 GMT+01:00 Alan Bateman < [ mailto:Alan.Bateman at oracle.com |
> Alan.Bateman at oracle.com ] > :

>> On 21/11/2017 09:29, Remi Forax wrote:

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

>> Good work was done in JDK 9 to get the plugin API to its current state. We had
>> hoped to expose it in an incubating module but it didn't happen as it would
>> have required splitting the jdk.jlink module in an awkward way. Yes, it should
>> be revisited.
>> -Alan