RFR: 8247373: ArraysSupport.newLength doc, test, and exception message

[Stuart Marks]

On Fri, 4 Dec 2020 19:13:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The preconditions aren't checked, because this is an internal method, and the code size is minimized in order to help inlining. That's also why `hugeLength` is a separate method. (I guess I could add comments to this effect.) With this in mind it's hard to reason about robustness. If prefLength is zero, this can only be because some precondition was violated (e.g., oldLength is negative). If this were to occur there doesn't seem to be any advantage choosing one undefined behavior over another.
>
> Is there a reason the code would not naturally work when either min or preferred is zero?
> Why are their preconditions?  What do they allow?
> These methods are used in enough places that a slip in any of the clients would be trouble and hard to track down.

The origin of this code is in collections like ArrayList that have an existing array (hence oldLength >= 0) and that need it to grow (hence minGrowth > 0). Those were the prevailing assumptions in the code from which this was derived, so they turn into preconditions here. I don't see the need to try to make this handle any more cases than it currently does. Doing so complicates the analysis and possibly the code as well. Certainly a bug in a caller might be difficult to track down, but I don't want to add argument checking or to provide "reasonable" behavior in the face of unreasonable inputs. This is an internal method; bugs in callers should be fixed.

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

PR: https://git.openjdk.java.net/jdk/pull/1617