On Wed, Jan 8, 2025 at 12:25 PM Alan Bateman <alan.bate...@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
