> On 4 Nov 2015, at 17:51, Mike Duigou <open...@duigou.org> wrote: > >> Date: Wed, 4 Nov 2015 15:32:25 +0100 >> From: Paul Sandoz <paul.san...@oracle.com> >> To: core-libs-dev <core-libs-dev@openjdk.java.net> >> Subject: RFR 8141409 Arrays.equals accepting a Comparator >> Please review: >> In addition i added an Objects.compare method, which simplifies the >> implementations of some object-bearing methods. > > Why not put the method on Comparable? >
I wanted it to be located with: public static boolean equals(Object a, Object b) public static <T> int compare(T a, T b, Comparator<? super T> c) > 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. 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. >
