<div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 8, 2025 at 12:25 PM Alan Bateman <<a href="mailto:alan.bateman@oracle.com" target="_blank">alan.bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
On 08/01/2025 17:57, David Lloyd wrote:<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div style="font-family:arial,helvetica,sans-serif">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.</div>
<br clear="all">
</div>
<div>
<div style="font-family:arial,helvetica,sans-serif">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.</div>
<div style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div style="font-family:arial,helvetica,sans-serif">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.</div>
</div>
<br>
</div>
</blockquote>
<br>
You can find previous discussion on this topic in JDK-8299504 [1]
and this mailing list [2].<br>
<br>
-Alan<br>
<br>
[1] <a href="https://bugs.openjdk.org/browse/JDK-8299504" target="_blank">https://bugs.openjdk.org/browse/JDK-8299504</a><br>
[2]
<a href="https://mail.openjdk.org/pipermail/jigsaw-dev/2023-April/thread.html#14846" target="_blank">https://mail.openjdk.org/pipermail/jigsaw-dev/2023-April/thread.html#14846</a><br>
</div>
</blockquote></div><div><br clear="all"></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I see, thanks.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><span style="font-family:arial,helvetica,sans-serif">The idea that optionality is only an edge case for e.g. annotations<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> (which seems to be these threads' concluding argument against lifting this validation)</span> <span class="gmail_default" style="font-family:arial,helvetica,sans-serif">does</span> not<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> seem to be</span> borne out in the trenches<span class="gmail_default" style="font-family:arial,helvetica,sans-serif">, as can be seen searching google or stack overflow for examples relating to static imports</span>. Additionally, optionality <span class="gmail_default" style="font-family:arial,helvetica,sans-serif">seems </span>orthogonal to service binding, yet they are bound together by this restriction.<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> </span></span><span style="font-family:arial,helvetica,sans-serif">Sometimes, the tradeoff of having a certain validation is greatly outweighed by the cost in convenience<span class="gmail_default" style="font-family:arial,helvetica,sans-serif">, power,</span> and expressibility. I believe this to be the case here, <span class="gmail_default" style="font-family:arial,helvetica,sans-serif">particularly </span>because I do not believe that there are any cases where the lack of this restriction would cause a worse outcome than having it<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> has caused</span>. 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). <span class="gmail_default" style="font-family:arial,helvetica,sans-serif">It seems hard to justify. </span>Thus I'm inclined to believe that this restriction does not serve any practical benefit, and I hope it can be reconsidered<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> to be respecified as a compile-time-only check</span>.</span></div><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Thanks.</div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div>
</div>