<div dir="ltr">The removal from the base module is straightforward and should continue in my opinion. The one from graphics is more troublesome because it will remove functionality that might otherwise be assumed and requires planning.<div><br></div><div>I suggest using the current PR for decoupling the base module and if a similar decoupling is done for the graphics module then it should be done in a different PR.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Nov 5, 2025 at 12:46 PM Marius Hanl <<a href="mailto:mariushanl@web.de">mariushanl@web.de</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"><div style="font-family:verdana;font-size:12px;color:rgb(0,0,0)">Thanks Nir for referencing the PR.</div>
<div style="font-family:verdana;font-size:12px;color:rgb(0,0,0)"> </div>
<div style="font-family:verdana;font-size:12px;color:rgb(0,0,0)">There are more information and detailed numbers on the PR, but to add some context:<br><br>I did some tests by making the java.desktop requirement static.<br>That is, java.desktop is not automatically pulled into your application.<br>If you need it, it need to be put in your <a href="http://module.info" target="_blank">module.info</a>, otherwise an exception is thrown as soon as a class from java.desktop is used.<br><br>When is java.desktop needed?</div>
<ul>
<li style="font-family:verdana;font-size:12px;color:rgb(0,0,0)">javafx.base: When using any of the Bean Property classes from javafx.beans.property.adapter</li>
<li style="font-family:verdana;font-size:12px;color:rgb(0,0,0)">javafx.graphics: When using the printing classes, e.g. PrinterJob.createPrinterJob().showPrintDialog(..), or if you want to use ImageIO to load e.g. TIFF or SVG files</li>
</ul>
<div style="font-family:verdana;font-size:12px;color:rgb(0,0,0)">Benefit:</div>
<div style="font-family:verdana;font-size:12px;color:rgb(0,0,0)">I created a modular Java runtime with JLink and measured the modules and disk size. Without java.desktop, the runtime got 13 MB smaller!<br>That is a nice decrease, especially if nothing what I mentioned above is needed. Creating a native installer like a .MSI will decrease the size further.</div>
<div style="font-family:verdana;font-size:12px;color:rgb(0,0,0)"> </div>
<div style="font-family:verdana;font-size:12px;color:rgb(0,0,0)">In my opinion, this is a great benefit. Unfortunately, as Kevin mentioned this is a somewhat incompatible change. So I'm interested in your opinion.<br>From my perspective, this is nice and if we don't want to go this route, I'm thinking for the first time ever about having a custom fork with this changes, which I would use for JLink (or can I easily patch those out when JLinking?).<br>I really don't like that, since now every other developer in the Team needs to build JFX, or take my custom JFX build.<br>But shipping a at least 13MB smaller .exe / even smaller .msi to the customer is very neat, also 'GreenIT' wise.</div>
<div style="font-family:verdana;font-size:12px;color:rgb(0,0,0)"> </div>
<div style="font-family:verdana;font-size:12px;color:rgb(0,0,0)">-- Marius</div>
<div style="font-family:verdana;font-size:12px;color:rgb(0,0,0)"><span style="background-color:rgb(255,255,255)"> </span></div>
<div id="m_6357829819861279709sub-body-container" style="margin:10px 5px 5px 10px;padding:10px 0px 10px 10px;border-left:2px solid rgb(195,217,229)">
<div style="margin:0px 0px 10px">
<div><strong>Gesendet: </strong>Mittwoch, 5. November 2025 um 10:56</div>
<div><strong>Von: </strong>"Nir Lisker" <<a href="mailto:nlisker@gmail.com" target="_blank">nlisker@gmail.com</a>></div>
<div><strong>An: </strong>"Kevin Rushforth" <<a href="mailto:kevin.rushforth@oracle.com" target="_blank">kevin.rushforth@oracle.com</a>></div>
<div><strong>CC: </strong><a href="mailto:openjfx-dev@openjdk.org" target="_blank">openjfx-dev@openjdk.org</a></div>
<div><strong>Betreff: </strong>Re: javafx.base and java.desktop</div>
</div>
<div>This is being implemented in <a href="https://github.com/openjdk/jfx/pull/1958" rel="noopener noreferrer" target="_blank">https://github.com/openjdk/jfx/pull/1958</a>.</div>
<br>
<div class="gmail_quote">
<div class="gmail_attr">On Sun, Nov 19, 2023 at 4:42 AM Nir Lisker <<a href="mailto:nlisker@gmail.com" rel="noopener noreferrer" target="_blank">nlisker@gmail.com</a>> wrote:</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(178,172,162)">Perhaps this is the right time to move this forward?</span></blockquote>
<div> </div>
<div>I don't see why not. Except for changing the `requires` declaration in the module-info and mentioning it in the docs, is there anything else that needs to be changed?</div>
</div>
<br>
<div class="gmail_quote">
<div class="gmail_attr">On Sat, Nov 18, 2023 at 7:48 PM Kevin Rushforth <<a href="mailto:kevin.rushforth@oracle.com" rel="noopener noreferrer" target="_blank">kevin.rushforth@oracle.com</a>> wrote:</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>We would need to validate the assertion that an app can't doing anything useful without the app itself importing and using java.beans from the java.desktop module.<br><br>At a minimum this would need a CSR specifying this additional requirement that the app must depend on java.desktop in order to use the JavaFX beans property adapter classes.<br><br>If others think this is useful, we could consider this for JavaFX 23.<br><br>-- Kevin<br><br>
<div>On 11/18/2023 6:16 AM, Kevin Rushforth wrote:</div>
<blockquote>
<blockquote>Perhaps the module can be declared 'requires static'.</blockquote>
<br>That was my thinking as well, which is captured in <a href="https://bugs.openjdk.org/browse/JDK-8240844" rel="noopener noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8240844</a><br><br>Perhaps this is the right time to move this forward?<br><br>-- Kevin<br><br><br>
<div>On 11/17/2023 4:06 PM, Nir Lisker wrote:</div>
<blockquote>
<div>
<div>Hi,</div>
<div> </div>
<div>A previous discussion mentioned the removal of AWT dependencies. One of the points that Kevin brought up was</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Refactor Java Beans implementation in javafx.base such that java.desktop is optional</blockquote>
<div> </div>
<div>John and I looked at this some time ago when we discussed the usage of the javafx base module outside of JavaFX, as its observables/binding capabilities are suitable for non-GUI applications, which currently have to pull in GUI modules as dependencies.</div>
<div> </div>
<div>The dependency is used in the property.adapter packages that bridge javafx.base properties with Java Beans. I think that these classes are seldom used.</div>
<div> </div>
<div>What could be a way to deal with that dependency? Perhaps the module can be declared 'requires static'. Or extract the adapter packages into a different "interop" module (javafx.javabeans) like javafx.swing?</div>
<div> </div>
<div>- Nir</div>
</div>
</blockquote>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote></div>