This check seems too strict. It is possible to implement a BufferedImage that splits its internal data into multiple surfaces/arrays. It might be better to phrase this as optional:
“for the specified format exceeds the maximum supported length”

I had looked at using a BandedRaster but there were a decent number of places that relied on the current format, even inside the JDK.
The work and compatibility concerns to address these are out of all proportion to simply documenting what has been true since the very beginning - 27 years plus - without a compelling reason.

The specification has the word "may" so it is not disallowed, but I think it would be risky.

The work and compatibility concerns to address these are out of all proportion to simply documenting what has been true since the very beginning - 27 years plus - without a compelling reason.

What compatibility impact? It has been throwing exceptions all this time, but currently it is allowed to work if we change that in the future, unlike the current proposal, which describes all implementation details as part of the specification, making it much harder to change later.

Instead we can mention "maximum supported length" in the spec and in the "impl section" mention that currently it is the size of the array/maxint,

The work and compatibility concerns to address these are out of all proportion to simply documenting what has been true since the very beginning - 27 years plus - without a compelling reason.

What compatibility impact?

That is in reponse to your suggestion to change the internal raster type. Not to a spec working change.

It has been throwing exceptions all this time, but currently it is allowed to work if we change that in the future, unlike the current proposal, which describes all implementation details as part of the specification, making it much harder to change later.

(1) No it allows leeway
(2) Even if it didn't we can relax it if there's ever a compelling enough reason - which I doubt we'll find.

Instead we can mention "maximum supported length" in the spec and in the "impl section" mention that currently it is the size of the array/maxint,

I don't see how that is better.

I don't see how that is better.

The specification will include a note about certain limitations, and under @implNote, we will describe the actual implementation-specific limitation. I believe that tag is appropriate in this context:

"@implNote" — Implementation Notes. This section contains informative notes about the implementation, such as advice for implementors or performance characteristics specific to this class in this version of the JDK. The information in this section may change from release to release. These characteristics may also vary across platforms, vendors, and JDK versions.

It is a statement of fact. Not an implNote.
If someone used different storage the clause would still be accurate even if there were no actual examples of it left.

If someone used different storage the clause would still be accurate even if there were no actual examples of it left.

I still would like to clarify, how the next statement could be correct if another storage is in use?

IllegalArgumentException if the multiplication product of
* {@code width}, {@code height}, and the number of samples per pixel
* for the specified format exceeds the maximum length of a Java array.

It is strictly required to throw this exception here and there, even if we will split the data across two arrays.