[External] : Re: provides and requires static ... runtime error

[Rob Bygrave]

*> As specified in ...*

Awesome, thanks for that.  Really nice to know that detail.


*> just add/remove artefacts to/from the module path to add/remove service
providers.*

That is true and will work for some folks but also presents an issue for
library authors with 000's of users who now have the ability to "stuff it
up" (by not including the dependency). The ideal is to not provide users
the option to "stuff it up" or at least have the default of "just works"
and especially when those users number in 000's (and tend to
reads documentation quickly, lightly, or not at all so we prefer to not
lend on docs if we can avoid it).

I'll put in a reply to Josiah that outlines a couple of options available
to avoid it / default to "just works".


Thanks again,
Cheers, Rob.



On Tue, 25 Apr 2023 at 18:41, Michał Kłeczek <michal at kleczek.org> wrote:

> As specified in
> https://help.intrexx.com/apidocs/jdk17/api/java.base/java/lang/module/Configuration.html#resolveAndBind(java.lang.module.ModuleFinder,java.util.List,java.lang.module.ModuleFinder,java.util.Collection)
>
> all modules reachable by a ModuleFinder are examined for uses-provides
> relationship and added to the set of resolved modules.
>
> It gives you the optionality: just add/remove artefacts to/from the module
> path to add/remove service providers.
>
> On 25 Apr 2023, at 03:39, Rob Bygrave <robin.bygrave at gmail.com> wrote:
>
> *> only y and y.inject must be in two separate JARs.*
>
> Does this work without *any* module having a `requires y.inject`?  If so,
> how is the y.inject module get included without a `requires y.inject`
> being specified? (There is an obvious follow up question if that is the
> case as it likely breaks the case where only y module is used).
>
>
> Cheers, Rob.
>
> On Tue, 25 Apr 2023 at 01:32, Ron Pressler <ron.pressler at oracle.com>
> wrote:
>
>>
>>
>> On 24 Apr 2023, at 14:23, Josiah Noel <josiahnoel at gmail.com> wrote:
>>
>>
>>
>>> I’m confused. To use the implementation of the `x.Plugin` service
>>> (defined in X) that you want Y to `provides` an implementation of, some
>>> module *must* have a `uses x.Plugin`. The runtime has to know that that
>>> service is needed by the program. Maybe the application `uses` it, but X
>>> itself could also declare that it `uses` an implementation of a service
>>> interface that it, itself, declares. So perhaps it is X that `uses
>>> X.plugin`, but someone has to actually say they want to use the service.
>>>
>>
>> I believe I'm picking up what you're putting down, but let's review it
>> again to be sure.
>>
>>
>> In artifact X we have:
>>
>>
>>>     exports x.spi;
>>>     uses x.spi.Plugin;
>>>
>>
>> in artifact Y we have two modules: y and y.inject.
>>
>>     exports y.stuff;
>>>
>>
>> And
>>
>>>     requires x;
>>>     provides x.spi.Plugin with y.inject.PluginImpl;
>>>
>>
>> With this in mind, we have two situations we want to support. we have an
>> application Z that wants to use the Y artifact alone and a case where Z
>> wants to use X and Y.
>>
>> With Y alone, the z module should look like this correct?
>>
>>     requires y;
>>>
>>
>>  And in the case where Z wants both X and Y (with X doing the
>> service-loading), we do:
>>
>>     requires x;
>>>     requires y;
>>>
>>
>> Am I right to understand that X will service load the y.inject plugin
>> correctly?
>>
>>
>> Yes.
>> This is also how it works today, only y and y.inject must be in two
>> separate JARs.
>>
>> — Ron
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20230426/e9f60dba/attachment.htm>