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

[Rob Bygrave]

*> Yes > Does this work without any module having a `requires y.inject`? *

Awesome.


*> If there is no module on the module path that uses the x.spi.Plugin, the
y.inject module will not resolve, and no exception will be thrown.*

Awesome.



*Summary: (as this thread has got massive)*

The suggested future Java that supports multiple modules in a single jar
would indeed solve this issue and "just works". To me at least, it looks
like it solves it *perfectly* without any negative side effects or
downsides.

The only followup questions I can see regarding multiple modules in a
single jar are:
- Would this solution be intended to work for older versions of Java at
runtime like Java 11? We probably can't answer this yet but open source
libs tend towards supporting a minimum version based on LTS for better or
worse (and will be keen to know if they can adopt this by using the latest
build tooling but still support older/existing java runtimes. If so, I
would think that would greatly help the adoption of the 2 modules in 1 jar
solution).
- For my own personal interest, what are the other motivations for
supporting multiple modules in a single jar? (If these other motivations
are high that improves our chances of seeing this solution happen)



*Workarounds today*

For myself as I see it the workarounds that are available today are:

- *[1] Not using ServiceLoader. This is relatively simple and has only 1
downside which is that the implementation must be in an exported package.
As such, this is still my preferred workaround (but it's certainly not the
ideal longer term solution).
- [2] Changing the design by "reversing the relationship" e.g x at runtime
detects y. This will work in some cases but isn't going to work generally
or at scale.
- [3] Splitting the artifact / Have a separate jar for the optional service
implementation
     - [3a] Make users aware of this and require the plugin dependency to
be explicitly included in the path. This is not ideal for the case where
there are 000s of users and now has "stuff it up" by default
behaviour (people forget to include the dependency).
     - [3b] Use a maven composite dependency and document/promote that as
the dependency to use (So 3 artifacts now, ok'ish).
     - **[3c] Use maven transitive dependency to by default transparently
include the plugin dependency (most closely matches the 2 modules in 1 jar
approach)

For people interested I have put a skeleton of this at:
https://github.com/rbygrave/skeleton-optional-service

For people interested, the top 2 workarounds today as I see them are:
*[1] Not using ServiceLoader.
**[3c] Use maven transitive dependency ... which I have as a PR at:
https://github.com/rbygrave/skeleton-optional-service/pull/1 This uses a
slightly dirty build trick to workaround the maven cyclical dependency.
This can be considered ok if the plugin implementation is very stable
(which I expect to hold true).


**[3c] To me this is the closest thing to the "2 modules in 1 jar" solution


Cheers, Rob.









On Tue, 25 Apr 2023 at 16:33, Josiah Noel <josiahnoel at gmail.com> wrote:

> Does this work without *any* module having a `requires y.inject`?
>>
>
> Yes.
>
> If so, how is the y.inject module get included without a `requires
>> y.inject` being specified?
>>
>
> It will resolve when a module uses the x.spi.Plugin it provides. (x in
> this case) Hence, there is no need for any module to require y.inject. (as
> it doesn't export anything).
>
> If there is no module on the module path that uses the x.spi.Plugin, the
> y.inject module will not resolve, and no exception will be thrown.
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20230426/2c69f656/attachment-0001.htm>