<div dir="ltr"><div class="gmail_default" style="font-family:monospace">Thank you very much for the response Alan! I spoke to the answerer on SO, and got all of this info added. Very much appreciated!</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Do you have any thoughts on the main question I asked? Java is doing amazing work to make programs faster and safer. Ultimately, my main question is to see if anything is being done to also minimize disk size of its generated binaries.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 12, 2024 at 5:07 AM 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 11/04/2024 23:37, David Alayachew wrote:<br>
    <blockquote type="cite">
      
      <div dir="ltr">:
        <div style="font-family:monospace" class="gmail_default"><br>
        </div>
        <div style="font-family:monospace" class="gmail_default">*
          There's the 2 modules -- java.base and java.desktop.
          Unfortunately, they also happen to be the 2 biggest modules in
          the entirety of the JDK. Sometimes, I wonder "Why are they
          that large? Could they have been broken down further? Might
          that happen in the future?"</div>
        <br>
      </div>
    </blockquote>
    <br>
    The SO post that you linked to doesn't mention --strip-debug which
    will strip the debug attributes from the class files. That should
    reduce the size by another few MBs but at the cost of less useful
    stack traces.<br>
    <br>
    There are at least 5 modules if you have included java.desktop. Look
    at the  "release" file in the top-level directory of the generated
    run-time image to see full set. You'll see java.xml in the set,
    another large module, because there are APIs in java.desktop
    (particularly in image I/O) that have XML types in method
    signatures.<br>
    <br>
    Almost all exploration in the past into splitting the APIs for
    AWT/Swing/Image/Sound/etc. into cohesive modules came to nothing
    because of all the cross references between these APIs. The
    exception is the java.awt.datatransfer module which provides
    something cohesive in non-UI contexts, e.g. XML binding and web
    services APIs. One thing that isn't there is a jlink plugin for
    limiting java.desktop to "headless mode", interesting for server
    environments that do things like process images and thus use APIs
    from the java.desktop module.<br>
    <br>
    So right now, I'm not aware of any effort to re-visit the
    java.desktop module. Efforts have tended to focus more on
    compression and reducing the size of existing bits. Maybe in the
    future that closed work assumptions could help but right now the API
    surface (and resulting implementation) is huge.<br>
    <br>
    -Alan<br>
    <br>
    <br>
    <br>
    <br>
    <br>
  </div>

</blockquote></div>