Hi, In https://github.com/openjdk/jfx/pull/1593, I saw some discussion about splitting the java.desktop module. In this discussion, I think Johan's point of view[1] is the most representative:
> 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. > > 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. 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. 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. I wonder if we can provide a new Image API: * Provides a unified abstraction for images, color space, pixel format, etc. These abstractions can be implemented by different vendors, such as AWT, JavaFX, Android, etc. * We should have a common and extensible interface for reading and writing images, so that libraries such as javax.imageio and JavaFX do not need to repeatedly implement reading and writing support for the same image format. This interface should be bidirectionally compatible with javax.imageio: The implementation of javax.imageio.spi can be regarded as the implementation of the new interface, and the implementation of the new interface can also be accessed through javax.imageio. I want to see if people think it's feasible and worth the effort. Glavo [1]: https://mail.openjdk.org/pipermail/openjfx-dev/2024-October/050042.html
