<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 Thu, Dec 19, 2024 at 7:58 AM Alan Bateman <<a href="mailto:alan.bateman@oracle.com">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 18/12/2024 15:09, David Lloyd wrote:<br>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div dir="ltr">
          <div style="font-family:arial,helvetica,sans-serif">:<br>
          </div>
        </div>
        <div class="gmail_quote">
          <div><br>
          </div>
          <div>
            <div style="font-family:arial,helvetica,sans-serif">No. Since
              we are late-binding all modules, every module we would
              load would start with no `requires`, and we use `addReads`
              on the controller to wire in the dependencies when the
              module is lazily linked.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I'm going to stop here as I think there is enough in this sentence
    to put context on where you are coming from and why some of the
    previous mails were a bit baffling.<br>
    <br>
    If I've compiled my code as a module then it will have declared its
    dependencs, it may use or provide services, and it might export some
    internal packages to other modules in the project.  I think your
    mail is suggesting that the module-info.class is modified, or
    substituted, in your system to not have any references to other
    modules. Once the module is reified by creating a single-module
    module-layer then read edges will be added dynamically. I assume
    that anything that uses APIs to examine the Module or
    ModuleDescriptor will see a module that only requires java.base.<br></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Right, though many of our "modules" won't actually have `module-info` at all, so we're essentially spinning them into automatic modules (though we prescribe the module name in many cases where the automatic module detected name is not good/clashes with another/etc.). IIRC this was the "concession" approach that was recommended for this use case back in the day (it was the outcome of some discussion or another, or maybe a call, I have notes somewhere), though we never got it to work at the time due in part to the services stuff.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    My view is that this direction is in a completely different design
    space to that of configurations and module layers. We did build an
    internal API to support very specific "dynamic module" use-cases in
    the JDK, e.g. some Proxy scenarios required do code gen into a
    dynamic code, same thing with code generation for RMI remove refs.
    We decided to not expose anything at this level as it's essentially
    the all powerful Unsafe API for modules.<br></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">If I could ask, what makes it unsafe? It only would apply to custom layers after all. There would be no way to crack open anything in the JDK or arbitrary memory (for example); I see access to a Controller as being analogous to having access to an original Lookup for my own app classes (but not the JDK itself of course, or anything else outside of the layer). The object itself is the permission.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Would you say that this is an inaccurate analogy?</div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">--</div></div><div>- DML • he/him</div></div></div>