On Thu, 5 Mar 2026 17:50:09 GMT, Phil Race <[email protected]> wrote:
>> This fix updates DataBuffer subclasses to actually adhere to their stated
>> specifications by rejecting certain invalid parameters for constructors and
>> getters and setters.
>> A new egression test for each of the constructor and getter/setter cases is
>> supplied.
>>
>> No existing regression tests fail with this change, and standard demos work.
>>
>> Problems caused by these changes are most likely to occur if the client has
>> a bug such that
>> - a client uses the constructors that accept an array and then supplies a
>> "size" that is greater than the array.
>> - a client uses the constructors that accept an array and then supplies a
>> "size" that is less than the array and then uses getter/setters that are
>> within the array but outside the range specified by size.
>>
>> Since very few clients (and just one case in the JDK that I found) even use
>> these array constructors the changes are unlikely to make a difference to
>> clients.
>>
>> The CSR is ready for review https://bugs.openjdk.org/browse/JDK-8378116
>
> Phil Race has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8377568
src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 183:
> 181: */
> 182: public DataBufferByte(byte[][] dataArray, int size) {
> 183: super(UNTRACKABLE, TYPE_BYTE, size, dataArray.length);
I guess there was no point in the explicit check for dataArray == null because
the dataArray.length expression above implicitly does it. I see no value in
trying to do anything to have the explicit check first, so I've removed all the
explicit checks that follow an implicit check.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2891396508
