RFR: 4617681: constructor of BufferedImage throws unexpected IllegalArgumentException [v2]

[Phil Race]

On Mon, 24 Nov 2025 22:50:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The spec update in question only applies to the pre-defined types.
>> I see no circumstance in which we'd ever modify the implementation of these.
>> 
>> I actually tried this (meaning BandedSampleModel) months ago now, for the 3BYTE_BGR case which is the one of those  with the biggest current constraint. ie. I changed the implementation of that case and found that printing, Image I/O and IIRC at least one
>> other thing I can't remember now assumed the current implementation.
>> They'd need to be re-worked first. I don't see this ever happening.
>> If internal code makes assumption, external code likely does too.
>> 
>> If we did add a new pre-defined type that can exceed these limits because it used a banded raster, then as part
>> of adding that, updating the spec for this case would be part of that. And that could never be backported anyway.
>
>> If we did add a new pre-defined type that can exceed these limits because it used a banded r
> 
> I agree with this. It will be hard to reimplement, but maybe we can still hint that this behavior depends on the implementation rather than specifying it strictly in the documentation?

It does not say that something like TYPE_4_BYTE_ABGR absolutely cannot use bands.
It just points out that if you use a smaller data buffer type you can store less data *in a DataBuffer* than with a larger one,
with the end result being more of a limitation on the image size.

This result just scales with the number of bands used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2586909864