Array equality, comparison and mismatch

[Paul Sandoz]

Hi Peter,

On 23 Sep 2015, at 10:09, Peter Levart <peter.levart at gmail.com> wrote:

> Hi Paul,
> 
> Just some thoughts about nulls...
> 

Thanks, this is helpful.


> Simple compare and compareUnsigned methods (without ranges) accept null arrays.

Yes.


> They specify that indirectly by stating that they are consistent with equals methods that do the same. The equals methods specify that two null array references are equal and by equal being an equivalence relation it follows that a null array reference is not equal to non-null reference (unless all arrays were equal),

Right, i had the indirect specification on both methods, but of course that makes no sense for unsigned comparison, so it was removed.


> but compare[Unsigned] methods do not specify the ordering of null to non-null array reference. The implementation does order null array reference before any non-null reference.

I have clarified the doc the all the byte[] compare/Unsigned methods:

* <p>A {@code null} array reference is considered lexicographically less
* than a non-{@code null} array reference.  Two {@code null} array
* references are considered equal.


> 
> With compare methods taking Object[] arrays there is another level of nullness to consider - the elements.

Yes.


> The Arrays boolean equals(Object[] a, Object[] b) method uses the semantics of Objects.equals for comparing elements, therefore it allows null elements. So does Arrays <T extends Comparable<? super T>> int compare(T[] a, T[] b), which considers null element as the lowest value. This seems ok although in TreeMap, for example, null keys are not allowed if Comparator is not specified, but for consistency with Arrays.equals this is a desired property. But Arrays <T> int compare(T[] a, T[] b, Comparator<? super T> cmp) does the same - it treats null elements as the lowest value. This is not consistent with TreeMap, for example, where all decisions on ordering are delegated to Comparator which can order null elements (or reject them) as it pleases.
> 

A good point. Same applies to mismatch as well. Updated.

There is another inconsistency. Array methods sort and binarySearch do not explicitly declare Comparable and instead this is implied if a null Comparator argument is given. I prefer separate methods for compare, making Comparable explicit, and throwing NPE for a null Comparator. the semantics are slightly different for mismatch where constraining elements to be of of Comparable is not necessary). However, for consistent i might be pushed towards sort/binarySearch pattern.

Thanks,
Paul.