> On 4 Nov 2015, at 22:41, Paul Sandoz <paul.san...@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. >>
