<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi,<div><br></div><div>In <a href="https://github.com/openjdk/jfx/pull/1593" target="_blank">https://github.com/openjdk/jfx/pull/1593</a>, I saw some discussion about splitting the java.desktop module.</div><div>In this discussion, I think Johan's point of view[1] is the most representative:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><pre style="color:rgb(0,0,0)">I totally agree. It is a (maintenance) nightmare to make sure the whole
java.desktop module is available and works on mobile and embedded, while
only a tiny fraction of it is used.
And even for purely desktop apps, the overhead of including the
java.desktop module in an application is significant. I often see people
comparing the binary size of a JavaFX app versus a similar Electron app,
and it's a pity that the size of JavaFX apps is negatively influenced by
something that is barely used (that is, most of the bytes in the
java.desktop module are never used in JavaFX).

In the ideal world, I think a more granular javax.imageio module could be a
solution. That could then be leveraged by the javafx modules.
Theoretically, the java.desktop maintainers could leverage that module as
well, and remove the internals from java.desktop, but that is not something
we should discuss on this list.</pre></blockquote><div><br></div><div>As a developer of JavaFX applications and a contributor to commons-imaging, I suffer from the coupling of the AWT Image API and the javax.imageio to java.desktop.</div><div>Besides the fact that java.desktop is too heavy, the more important problem is that Android does not provide support for it, which makes it considered non-universal.</div><div>But after I checked the API, I thought it's not possible to split them from java.desktop, they have many dependencies on other parts of java.desktop.</div><div><br></div><div>I wonder if we can provide a new Image API:</div><div><br></div><div>* Provides a unified abstraction for images, color space, pixel format, etc.</div><div>  These abstractions can be implemented by different vendors, such as AWT, JavaFX, Android, etc.</div><div>* We should have a common and extensible interface for reading and writing images, </div><div>  so that libraries such as javax.imageio and JavaFX do not need to repeatedly implement reading and writing support for the same image format.</div><div>  This interface should be bidirectionally compatible with javax.imageio: </div><div>  The implementation of javax.imageio.spi can be regarded as the implementation of the new interface,</div><div>  and the implementation of the new interface can also be accessed through javax.imageio.</div><div><br></div><div>I want to see if people think it's feasible and worth the effort.</div><div><br></div><div>Glavo</div><div><br></div><div>[1]: <a href="https://mail.openjdk.org/pipermail/openjfx-dev/2024-October/050042.html" target="_blank">https://mail.openjdk.org/pipermail/openjfx-dev/2024-October/050042.html</a></div></div></div>
</div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div></div></div></div>
</div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div></div></div></div>