On Fri, 4 Dec 2020 19:13:45 GMT, Roger Riggs <rri...@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
