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