I started replying to this a couple of times, but I never finished it, because 1) there are many different angles to look at the question 2) I believe it is indeed pretty hard.
However, I absolutely understand the original question, and I support the idea. The fragmentation of "image" handling is a pain for many developers, and it doesn't help the adoption of JavaFX (or AWT). Realistically, I believe that in order to fix this issue, a considerable investment (resources) is needed, and even then it will take a long time. I think we can only talk about those AWT/JavaFX, and not about Android. While the OpenJDK and OpenJFX process is relatively open (with a high technical barrier, for good reasons) and allows for participation from different companies, organisations and individuals, the Android process is a different beast and I believe the chances that anyone on that side is interested in my opinion are close to 0. That is one of the reasons why I'm working on OpenJDK/Mobile, as that allows to run the real Java on Android devices (basically, this is close to running Android on embedded linux systems). We have JavaFX working on Android, so the JavaFX image API's work on Android-devices. For those not familiar with OpenJDK/Mobile and the way we do things at Gluon: we bundle Java application code and dependencies with a hotspot-based JVM which is contained in a native library for Android, and which can then be invoked from a plain Android Activity. We have cross-compiled versions of the JavaFX libraries (including the imageio libs) for Android, so those can be used. While this is technically feasible (and I can address the typical critics about footprint size and performance), this is not mainstream. Given the enormous marketing power of Android versus the very limited resources we have, this is not surprising, and I don't think we should discuss this in this thread. A common image API needs an API and implementations. John made excellent points about the required flexibility of the API [1] (e.g. allow for a trade-off between memory and performance). A good API allows developers to deal with this, and we are far from there. Today, you actually need to look at the implementation if you want to understand what is happening, and what the impact is on CPU/memory. Handling this requires excellent API design, lots of discussions with different actors and different usecases. This is absolutely doable, but it is a major effort. The other thing is the native, platform-specific implementation. This is where the AWT parts and the JavaFX parts are conflicting. I don't recall the exact place, but when creating static builds of the AWT libraries and the JavaFX libraries on Linux, there were duplicate symbols, delivered by 2 different sources. It is not simply supporting different platforms, as there are a number of partially overlapping and partially conflicting low-level libraries for different formats/operations. JavaFX and java.desktop don't have the exact same set of requirements for this. This is something I ran into as well while working on building OpenJFX using the OpenJDK build system [2] (although it is not really problematic in this case, as we have 2 separate shared libs (1 for AWT and 1 for JavaFX) that do not need to be combined into a single executable). Both OpenJDK and OpenJFX contain a local version of libjpeg, but with a different version. In OpenJDK, you can build using a system-provided version of libjpeg. In order to have a single image API, those issues need to be fixed and the approach needs to be streamlined. One of the hard things in that case is, as Phil mentioned [3] that the java.desktop module is not internally modular. It would require precision surgery to separate the native dependencies required for image handling only from the rest of the module. With an open and honest blog post from Amy Fowler about Swing/AWT versus JavaFX in mind [4] (15 years ago!), I assumed that, contrary to all other modules in openjdk, an internal cleanup of java.desktop was not high priority, given the suggested path for UI development in Java. My personal opinion here is that I'm not really sure a new image API needs to be backward compatible with java.desktop, and it would make it easier if it was targeting JavaFX only. In summary, I absolutely support the idea of a new (common) image API. I see a number of challenges in different sub-parts (API design, native code integration between OpenJDK and OpenJFX), but I don't think I see technical showstoppers. The amount of work to do this properly, in a maintainable way, with the quality one expects from OpenJDK projects, should not be underestimated though. - Johan [1] https://mail.openjdk.org/pipermail/openjfx-dev/2025-April/053661.html [2] https://mail.openjdk.org/pipermail/openjfx-dev/2025-March/053076.html [3] https://mail.openjdk.org/pipermail/openjfx-dev/2025-April/053686.html [4] https://amyfowlersblog.wordpress.com/2010/09/21/a-heartfelt-ramble-on-swing-javafx/ On Thu, Apr 17, 2025 at 6:58 PM Scott Palmer <swpal...@gmail.com> wrote: > I think a common image I/O library that is not tied to a UI > framework makes sense and is long overdue. > Raster images do have a common format that encapsulates everything. We > essentially have this abstracted in the two UI frameworks already. At some > level it comes down to PixelFormats and data buffers. There are not so > many of them that it is impossible to make a common abstraction for the > purposes of I/O that can be mapped to what is needed by the UI framework. > Just as JavaFX already has the SwingFxUtils for converting between AWT and > JavaFX formats, there can be a utility to convert between the I/O library > format and each UI framework's format. I would expect in most cases that > the raw pixel data could be shared without extra copying. > ImageIO is a good starting point. Remove the actual UI classes from it > like BufferedImage and keep plain raster representations of the data that > can be wrapped by the UI classes. Under the hood the arrays or buffers of > raster data don't have to change,they are the important parts that the I/O > library needs to deal with. Mapping the metadata (width, height, colour > space, pixel format, etc.) will usually be very cheap. Some cases may need > to run a conversion, like the example of 1-bpp black/white needing to be > remapped to RGB, but that that can happen in the utility layer that moves > the image from the Image I/O domain to the UI framework domain on a > case-by-case basis. Worst case is that the UI framework throws an > UnsupportImageFormat exception when it doesn't have code to deal with > raster data in a particular format. > > I'm sure it is all much harder than I suspect, but I don't think it should > be. :-) > > Scott > > > On Thu, Apr 17, 2025 at 12:10 AM Philip Race <philip.r...@oracle.com> > wrote: > >> First, note than John Neffenger replied to this but only on openjfx-dev >> and the first thing I saw was the reply and couldn't see the original. >> After some consternation I tracked down this cross-post. >> >> Here's a link to the reply >> https://mail.openjdk.org/pipermail/openjfx-dev/2025-April/053616.html >> >> A fundamental problem is that all the users need to be able to produce >> and consume the data. >> So there either needs to be a module dependency (not viable) or an >> agreed format (are we >> really going to define an image format which encapsulates everything, >> including the multi-frame >> GIF support) and then everyone needs a reader and don't forget writers >> and they need to be able to do .. so much .. >> >> I just don't see a viable path here. >> And several (8 ?) years ago, I pondered some way to separate image >> handling from the >> desktop module to see if a server app could use it without pulling in >> AWT but the intra-package >> dependencies made it impossible without changes I didn't even figure out >> if they were possible. >> >> -phil. >> >> On 4/16/25 3:04 AM, Glavo wrote: >> > Currently, there are multiple different image APIs in the Java >> > ecosystem: AWT, JavaFX, Android, etc. >> > What's worse, the Android platform does not provide support for AWT, >> > making the Java ecosystem even more fragmented. >> > >> > There are some obvious problems with the current situation: >> > >> > * Third-party libraries that need an image API are difficult to be >> > universal. >> > A practical example: Apache Commons Imaging has been in the alpha >> > stage and cannot release version 1.0. >> > The main reason is that it depends on `java.awt.image`, so it >> > doesn't work on Android. >> > We hope to solve this problem before the official release. >> > * Different image APIs have to repeatedly implement support for >> > reading the same image format (such as JPEG). >> > In fact, AWT, JavaFX, and Android now each implement reading JPEG >> > images. >> > This is a waste. >> > >> > I thought we might be able to create a new module independent of >> > java.desktop that provides a common abstraction for images. >> > It should: >> > >> > * Provides common Image and ImageProvider interfaces that can be >> > implemented by different providers. >> > * Provides a unified abstraction for colors, color spaces, pixel >> > formats, etc. >> > * Provides general and extensible image I/O support. >> > Read/write support should only need to be implemented once per image >> > format. >> > It should be bidirectionally compatible with `javax.imageio`: >> > The implementation of either API can be accessed through the other >> API. >> > >> > I want to know if this is an idea worth putting into practice? >> > I'm not an expert in this field, so I'm worried about creating designs >> > with many flaws. >> > Therefore, I haven't attempted to implement it yet. >> > If anyone is willing to implement it, I'd like to help. >> > >> > I had sent an email a few days ago but no one responded, so I >> > re-edited it and sent this one. >> > >> > Glavo >> > >> >>
