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

Gunnar Morling gunnar at hibernate.org
Tue Dec 12 20:42:19 UTC 2017


Finally got to write about my explorations of the jlink plug-in API:
http://in.relation.to/2017/12/12/exploring-jlink-plugin-api-in-java-9/.

I found the API good to work with overall, implementing my use case (adding
an annotation index for given modules) was straight-forward.

One useful change could be to split up
ResourcePoolEntry$Type#CLASS_OR_RESOURCE into two separate enum members. I
think it's a common requirement to perform some action *only* for class
files, I found myself checking the entry path for the "class" suffix to do
so.

It'd be fantastic if the API could be promoted to "Incubating", perhaps in
Java 11?

--Gunnar




2017-11-22 12:59 GMT+01:00 <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 <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
>>
>
>


More information about the jigsaw-dev mailing list