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

[Rob Bygrave]

> Ron: I’m guessing that what’s bothering you isn’t so much the number of
*modules* but the number of JARs. So I think a more general solution than
adding a way to describe “this service is conditional on the presence of X”
would be to allow multiple modules in a single JAR that would contain both
Y and the X-Y-plugin.

How would this solve the issue? I can't see how having a second module on
the same jar/artifact would work for this case.

Bearing in mind this library needs to support both classpath and
module-path.

If a y.jar could include 2 module definitions say y and y.x what would be
defined in y.x that solve this issue? Can you be more explicit Ron? (I
can't see this working tbh)

Instead of a second module my gut says that what would solve this is a:

 'provides static'

... where that explicitly means that runtime module resolution should allow
the service interface to not exist.


Cheers, Rob.


On Fri, 21 Apr 2023, 1:56 am Josiah Noel, <josiahnoel at gmail.com> wrote:

> The reason why this could be considered acceptable is because the
>> implementation of x.spi.Plugin that would exist in Y can be hidden / not
>> exported and not open to abuse / accidental use.
>>
>
> This also helps resolve that concern on the bug report.
>
> All of this boils down to: if the implementation module says `provides`,
>> then is it reasonable to consider that ServiceLoader is the *only* vector
>> by which the implementation class will be instantiated? If yes, then module
>> resolution should perhaps be tolerant of a `provides` that specifies a
>> missing service interface. If no -- that is, we think arbitrary code might
>> instantiate (hence load) the implementation class -- then module resolution
>> is correct as-is.
>
>
> if we don't export the implementation class, then the
> ServiceLoader becomes the only mechanism by which it can be instantiated.
> In this case, if the user doesn't add the optional interface dependency, it
> becomes impossible to accidentally load the interface and get a
> ClassNotFoundException when using module Y's non-SPI packages.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20230423/1c79af28/attachment.htm>