<!DOCTYPE html><html><head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body>

    On 11/04/2024 23:37, David Alayachew wrote:<br>

    <blockquote type="cite" cite="mid:CAA9v-_OQnFk-Pm71MTyYnXw=htYdkcq-MDjvoCx3N6upL6hOGA@mail.gmail.com">

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

  </body>

</html>