<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 gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Jan 10, 2025 at 11:22 AM Magnus Ihse Bursie <<a href="mailto:magnus.ihse.bursie@oracle.com">magnus.ihse.bursie@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>
    <p>On 2025-01-08 22:33, David Lloyd wrote:</p>
    <blockquote type="cite">
      <div><span style="font-family:arial,helvetica,sans-serif">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>
    </blockquote>
    <p>I agree. I was bitten by this as a Java developer in a hobby open
      source project, and even if at some point I understood why things
      where the way they are, I do not remember the reasoning, and I
      still find it confusing that it did not work as I expected it to,
      nor what steps I were supposed to take instead to resolve the
      problem at hand.</p>
    <p>I understand that this is not a very common problem or a
      high-priority issue, and I would have accepted that it was
      down-prioritized to the point that it will take a long time to
      resolve, but the current "works as intended" approach is still a
      bit hard for me to swallow.</p></div></blockquote></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I think there's a bit of self-selection: this kind of problem mostly appears in more complex systems; the work to move complex systems to JPMS is already nonzero; complex systems do not move because of this kind of problem; therefore, the problem is considered a non-issue because nobody is complaining about it.</div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">As an experimental workaround I was trimming optional dependencies from the descriptor at run time and doing a late `addReads` instead if the dependency is present. This part works fine, however I then also have to strip out `uses` and sometimes `provides` for this to work if they correspond to packages in the optional dependency (which is a check that also incurs a run time cost), and adding those back to the module late requires hacky workarounds: for `addUses` I have to generate a class into the target module so that it can call `Module.addUses` on my behalf, and for `addProvides`, I have to access private JDK internals thus requiring `--add-exports` of a core JDK package, which is less than ideal. I did propose a patch to allow controllers to add these but it was soundly rejected and the ensuing discussion yielded little of value. So hopefully we can get around it another way: by allowing `uses` and `provides` of services whose packages are not present at run time.</div></div><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>