Java Arrays.sort throws exception

[Philipp]

My money is on some kind of bug in compareTo too. I don't see what else
it can be.

Could it be that the comparator must be consistent with equals for the
sort to work?

Phil

 

[Philipp]

That would be Owen's point.

I understood it as: "the comparator itself is not fulfilling its
contract". Contract which is (for the OP, see also "Effective Java" by
Bloch, Item 11):

Transitive:
(x.compareTo(y)>0 && y.compareTo(z)>0) implies x.compareTo(z)>0

Symmetric:
sgn(x.compareTo(y)) == -sgn(y.compareTo(x))
in particular x.compareTo(y) must throw an exception if and only if
y.compareTo(x) throws an exception

Coherence:
x.compareTo(y) == 0 implies that
sgn(x.compareTo(z)) == sgn(y.compareTo(z))

Phil

 

[Patricia Shanahan]

captain said :

captain, why are you using a label? That is highly unidiomatic.

I'm not sure whether it is part of captain's code, and therefore a
label, or outside the code, saying that the add call is in a loop.

I really hope captain is off either writing an SSCCE, or unit testing
the compareTo or compare method.

Patricia

 

[Tom Anderson]

This is my very first post and I am not up on the etiquete yet.

I realize that the problem must be in my code. Actually, I didn't
right this code, I inherited it. I have a lot of programming
experience but not in this particular environment.
[...]

It is astonishing, or perhaps sobering or depressing, to
find that someone with "a lot of programming experience" is
unable to form a coherent problem report nor able to produce
a usable test case.

I'm guessing that the 'programming' is the type they have on TV. In this
case, probably watched with a beer in hand, packet of cheetos in lap,
trucker cap on head, and drool escaping from mouth.

tom

 

[Owen Jacobson]

That would be Owen's point.

Not as such. My point was that identities like a < b && b < c is
implied by and implies that a < c, along with simpler ones like a < b
implies that b > a, must be implemented by the compareTo or compare
method in use. None of the sort implementations in the JRE bother
checking for .equals equality; they rely on .compareTo/.compare
equality.

-o

 

[Roedy Green]

captain, why are you using a label? That is highly unidiomatic.

I presumed pseudocode.

 

[Roedy Green]

I'm guessing that the 'programming' is the type they have on TV.

it could be simply some quite different language, like LISP.

 

[Roedy Green]

It is much more likely that the OP's compareTo is inconsistent with
itself, so that it does not represent a total order.

consider that the sort also uses Comparator.compare where the
algorithm rarely has any connection whatsoever to equals.

 

[Tom Anderson]

it could be simply some quite different language, like LISP.

I doubt it. Programming is basically the same in all languages, just with
different spelling. The idea that we could diagnose a problem in which
library routine A calls user-written routine B without seeing the text of
routine B is pretty bizarre in any language.

Also, i believe LISPers tend to be towards the smarter end of the spectrum
of programmers, and this guy, well, not so much,

If we widen the definition of 'programming' to mean 'coding', i could
maybe believe he was experienced with HTML, or something else really,
really unlike a programming language. Maybe perl?

tom

 

[Patricia Shanahan]

And yet the Javadocs for Comparator make a big deal out it. Why should
they do that if it doesn't matter?

It matters, but not for Arrays.sort.

The issue they discuss is a class, such as TreeSet, that is bound by an
contract described in terms of equals, but that will fail to conform to
it unless the Comparator is consistent with equals.

The Arrays.sort contract does not depend on equals, so it can fully
conform to its contract provided the Comparator represents a total order
over the array elements, regardless of whether that order is consistent
with equals.

Patricia