`requires static` versus service binding

[David Lloyd]

On Wed, Jan 8, 2025 at 12:25 PM Alan Bateman <alan.bateman at oracle.com>
wrote:

> On 08/01/2025 17:57, David Lloyd wrote:
>
> It is not uncommon for a library to contain a provider for a service where
> the service resides in an optional dependency. It is also sometimes
> desirable to use a service from an optional dependency.
>
> In JPMS, we can use `requires static` to indicate that the library will
> function without the dependency being present. We can declare that we use
> or provide a service from the optional dependency. Compilation will
> complete successfully in this case, because the descriptor is valid.
>
> However, at run time, the module will fail to resolve if any provider or
> uses comes from a module that is not present when the layer is resolved.
> This is not desired behavior, because the user has already opted in to and
> indicated that the dependency in question is optional, and should not cause
> a run time problem if not present.
>
>
> You can find previous discussion on this topic in JDK-8299504 [1] and this
> mailing list [2].
>
> -Alan
>
> [1] https://bugs.openjdk.org/browse/JDK-8299504
> [2]
> https://mail.openjdk.org/pipermail/jigsaw-dev/2023-April/thread.html#14846
>

I see, thanks.

The idea that optionality is only an edge case for e.g. annotations (which
seems to be these threads' concluding argument against lifting this
validation) does not seem to be borne out in the trenches, as can be seen
searching google or stack overflow for examples relating to static imports.
Additionally, optionality seems orthogonal to service binding, yet they are
bound together by this restriction. Sometimes, the tradeoff of having a
certain validation is greatly outweighed by the cost in convenience, power,
and expressibility. I believe this to be the case here, particularly because
I do not believe that there are any cases where the lack of this
restriction would cause a worse outcome than having it has caused. I for
one have never heard of a single case where a program experienced a problem
as a result of a lack of a validation like this even in the old "JAR hell"
days. However, it seems that the additional restriction does periodically
bite users in general (not just us). It seems hard to justify. Thus I'm
inclined to believe that this restriction does not serve any practical
benefit, and I hope it can be reconsidered to be respecified as a
compile-time-only check.

Thanks.

-- 
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20250108/351a51b9/attachment.htm>