On Sat, 5 Dec 2020 02:37:55 GMT, Stuart Marks <sma...@openjdk.org> wrote:
>> 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. The algorithm can be well defined for minGrowth and prefGrowth == 0 without extra checks or exceptions with a careful look at the inequality checks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1617
