RFR: 8369129: Raster createPackedRaster methods specification clean up [v4]

[Phil Race]

On Sat, 18 Oct 2025 06:05:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> PS, also negative strides are something that we've been asked to support too - in the distant past.
>> But I don't have any plans to do it now.
>
>>We seem to have a number of APIs that allow the strides to be zero.
>>I find them odd, but I don't see how they can cause an empty image 
> 
> If the  scanlineStride and pixelStride are zero then the size below will be set to zero as well, even if we try to prevent that by checking the w and h to be > 0 before.
> 
> lsz = (long)scanlineStride * (long)(h - 1) + // first (h - 1) scans
>       (long)pixelStride * (long)w; // last scan
> int size = (int)lsz;
> .....
> d = new DataBufferByte(size);

I've played around a bit.
Commenting specifically about the one createInterleavedRaster factory method which accepts, width, height and the strides, I don't think such cases of zero pixel stride have ever been useful.
I've written a small test (which I'll paste below) and as far as I've found so far, a zero pixel or scan line stride always results in an exception
from somewhere. And the exceptions are the same for each case. I've tried JDK 8, JDK 24 and a build of the current proposed fix.

So I think we could explicitly disallow 0 for these strides on this method although rather than a mix
of  RasterFormatException and IllegalArgumentException, they'd all become IllegalArgumentException

For the  other public factory method createInterleavedRaster that accepts a DataBuffer,  even if the app makes it large enough,
there's still an exception in most cases. The sole "working" case I've found is if bandoffsets are also all zero.

 Raster.createInterleavedRaster(new DataBufferByte(100), 1, 1, 0, 0, new int[] { 0 });

To continue to allow that we'd need to still allow zero strides on that method and use words about the bandoffsets.

The words about the bandOffsets should in fact go on both methods. They apply more broadly than a zero stride.

I'll proceed accordingly unless you spot an issue. Also I'll need to run all our tests which I've not done yet.

I don't intend to look at the allowability of zero in other APIs as part of this change.

BTW negative strides was asked for here : https://bugs.openjdk.org/browse/JDK-4296691
 
I don't think we'll ever do that.

test program :
import static java.awt.image.DataBuffer.TYPE_BYTE ;
import java.awt.image.Raster;

public class ZeroStride {
    public static void main(String[] args) {
        //   w  h  ss ps           bandoffsets
        test(1, 1, 0, 0, new int[] { 0, 0, 0});
        test(1, 1, 0, 0, new int[] { 0, 1, 2});
        test(1, 1, 0, 1, new int[] { 0, 0, 0});
        test(1, 1, 3, 0, new int[] { 0, 0, 0});
        test(1, 1, 3, 0, new int[] { 0, 1, 2});
    }

    static void test(int w, int h, int scanlineStride, int pixelStride, int[] offsets) {
        try {
             System.err.println("w="+w+" h=" + h + " scanlineStride=" + scanlineStride +
                                " pixelStride = " + pixelStride +
                                ((offsets[1] == 0) ? " bands={0,0,0}" : " bands={0,1,2}"));
             Raster.createInterleavedRaster(TYPE_BYTE, w, h, scanlineStride, pixelStride, offsets, null);
             System.err.println("No exception");
        } catch (Exception e) {
             e.printStackTrace();
        }
        System.err.println();
    }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27627#discussion_r2446128878