RFR: 4617681: constructor of BufferedImage throws unexpected IllegalArgumentException

[Phil Race]

On Tue, 4 Nov 2025 01:27:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I see that none of the code path under this API uses BandedSampleModel.
>> 
>> We can continue to create DataBuffer to hold >Integer.MAX_VALUE and use it to create a Raster with BandedSampleModel and then create a BufferedImage out of it.
>> 
>> 
>> import java.awt.Transparency;
>> import java.awt.color.ColorSpace;
>> import java.awt.image.BandedSampleModel;
>> import java.awt.image.BufferedImage;
>> import java.awt.image.ColorModel;
>> import java.awt.image.ComponentColorModel;
>> import java.awt.image.DataBuffer;
>> import java.awt.image.DataBufferByte;
>> import java.awt.image.Raster;
>> import java.awt.image.WritableRaster;
>> 
>> public class BandedBufferedImage {
>>     public static void main (String[] args) {
>>         int width = 1;
>>         int height = Integer.MAX_VALUE - 5;
>>         int numBands = 3; // For RGB
>>         int dataType = DataBuffer.TYPE_BYTE; // 8-bit per band
>> 
>>         // Create arrays for bank indices and band offsets
>>         int[] bankIndices = new int[numBands];
>>         int[] bandOffsets = new int[numBands];
>>         for (int i = 0; i < numBands; i++) {
>>             bankIndices[i] = i; // Each band in its own bank
>>             bandOffsets[i] = 0; // Offset within each bank
>>         }
>> 
>>         BandedSampleModel sampleModel = new BandedSampleModel(
>>             dataType, width, height, width, bankIndices, bandOffsets
>>         );
>>         DataBuffer dataBuffer = new DataBufferByte(width * height, numBands);
>>         WritableRaster raster = Raster.createWritableRaster(sampleModel, dataBuffer, null);
>>         ColorSpace cs = ColorSpace.getInstance(ColorSpace.CS_sRGB);
>>         int[] bits = {8, 8, 8}; // 8 bits per color component (R, G, B)
>>         ColorModel colorModel = new ComponentColorModel(cs, bits, false, false, Transparency.OPAQUE, dataType);
>>         BufferedImage bufferedImage = new BufferedImage(colorModel, raster, false, null);
>>     }
>> }
>> 
>> 
>> So there are no restrictions on these values. Even if someone extends ComponentSampleModel and divides data into separate bands they can continue to do so.
>
>>I see that none of the code path under this API uses BandedSampleModel.
> 
> This discussion is about the possibility of changing that in the future. The current change prevents us from implementing those for large images(even by simply reusing BandedSampleModel instead of new class), since it includes strict limits and the TCK will enforce them. So, if we decide to change it later, we’ll also need to update the specification, which means the change can’t be backported.
> 
>>But that seems nearly impossible. There's too many things in the spec. and implementation that would need revisision.
> 
> What things? I don’t think we have any limits, except that we still need to implement it. Right now, we don’t define that behavior clearly. So, later, the user will get the correct large image when they ask for it, instead of getting an error. But the current patch is one of the thing which will prevent that, no?

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.

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

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