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
