RFR: 4617681: constructor of BufferedImage throws unexpected IllegalArgumentException
Phil Race
prr at openjdk.org
Tue Oct 14 16:20:46 UTC 2025
On Mon, 13 Oct 2025 21:38:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:
>> Do you have a conformant sample implementation that we could consider ?
>
>> Do you have a conformant sample implementation that we could consider ?
>
> We already have an implementation of BandedSampleModel and buffers that store color components in separate bands (different arrays). Similarly, we can implement a new subclass of ComponentSampleModel that stores "x lines of the image per bank".
> And it should be possible to reuse an existed api of buffers like: https://github.com/openjdk/jdk/blob/4ca4485e9af10a49ca95710c4e26aa3895835d47/src/java.desktop/share/classes/java/awt/image/DataBufferInt.java#L254
>
> Initially these images will the slowest loops, but we can add some new here and there.
BandedSampleModel is not precluded by the current proposed wording, in fact it is explicitly accommodated.
The spec. for BandedSampleModel has this as its first sentence :
This class represents image data which is stored in a band interleaved fashion and for which each sample of a pixel occupies one data element of the DataBuffer
I had actually thought already about the way you suggest with splitting an image so that different parts of it
are in different data buffers. But that seems nearly impossible. There's too many things in the spec. and
implementation that would need revisision. I see no value in diluting the wording to allow an impossibility.
If we ever did that (unlikely) then revising these few words in the spec. would be an insignificant part of it.
Essentially the proposed spec is saying is "array length imposes a hard limit".
So I do not see any problem with the spec as proposed.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2429749880
More information about the client-libs-dev
mailing list