<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>