RFR 8141409 Arrays.equals accepting a Comparator

Paul Sandoz paul.sandoz at oracle.com
Thu Nov 5 08:56:52 UTC 2015


> On 4 Nov 2015, at 22:41, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
> 
>> The null handling choice seems arbitrary.
> 
> I wanted Arrays.equals to be consistent with the Comparable accepting Arrays.compare and Arrays.mismatch, so it was a coin toss between nulls first and nulls last, hence that choice is propagated to Objects.compare, which is consistent with Objects.equals.
> 

Now i recall some more details on the decision I took. Less of a coin toss than it first appears.

Null array refs are also supported for Arrays.compare, again so as to be consistent with Arrays.equals. And it’s “natural” to consider a null array ref to be less than a non-null array ref value, since null is essentially 0 bits set, and by logical progression that can apply to any ref value.

So there are two forces pushing the design in different directions:

1) null-consistency with Arrays.equals behaviour, the current approach (and note that Arrays.mismatch does not support null array refs, and nor do the sub-range methods); and

2) consistency with Arrays.sort/binarySearch/TreeMap, where null array refs would not be supported and null elements would only be supported when an explicit null-supporting Comparator is used.

Would developers expect:

  Arrays.equals(a, b) == (Arrays.compare(a, b) == 0)

or:

  Arrays.compare(a, b) // potentially throws NPE
  Arrays.equals(a, b) == (Arrays.compare(a, b, Comparator.nullsFirst(Comparator.naturalOrder())) == 0)
  Arrays.equals(a, b) == (Arrays.compare(a, b, Comparator.nullsLast(Comparator.naturalOrder())) == 0)

?

Paul.

> The other solution, as you suggest out, is to ditch support Comparable null values, where a certain choice is picked. for the relevant Comparable accepting Arrays methods. That would be more consistent with existing operations on Comparables, such as Arrays.sort etc.  and for consistency with Arrays.equals a null accepting Comparator would need to be used with the relevant methods on Arrays.
> 
> Hmm… now you have me rethinking this :-) thoughts?
> 
> Paul.
> 
>> Nulls last or nulls disallowed would be equally valid. As usual I favour nulls disallowed.
>> 




More information about the core-libs-dev mailing list