> On 10 May 2019, at 09:52, Peter Levart <peter.lev...@gmail.com> wrote:
>
> <snip>
>
> Is there a case where returning > MAX_ARRAY_SIZE will not lead to OOME?
>
> If this utility method is meant for re-sizing arrays only (currently it is
> only used for that), then perhaps the method could throw OOME explicitly in
> this case. You already throw OOME for the overflow case, so currently the
> method is not uniform in returning exceptional values (i.e. values that lead
> to exceptions).
>
> Unless you expect some VMs to tolerate arrays as large as Integer.MAX_VALUE ?
I think the proposed behaviour is equivalent to what there is now. After all,
it's a refactoring effort and as such *should* result in equivalent behaviour.
If understand you correctly, your question can be answered by answering
Why there is MAX_ARRAY_SIZE in the first place?
> These lines:
>
> 607 int newCapacity = oldCapacity + preferredGrowBy;
> 608 if (preferredGrowBy < growAtLeastBy) {
> 609 newCapacity = oldCapacity + growAtLeastBy;
> 610 }
>
> ...could perhaps be more easily grasped as:
>
> int newCapacity = oldCapacity + Math.max(preferredGrowBy, growAtLeastBy);
I'm not an expert here, but if I understood Ivan correctly, the purpose was to
avoid branching. Maybe intrinsified Math.max is superior in both readability and
performance. I simply don't know. If you feel strongly about using it, you could
maybe compare those approaches by benchmarking.
