On Tue, 7 Oct 2025 23:16:36 GMT, Sergey Bylokhov <[email protected]> wrote:
>>> > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2412196131
