Hi Peter,
On 23 Sep 2015, at 10:09, Peter Levart <peter.lev...@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.
