java.lang.ClassCastException in Collections

Any reasonable sized application may have ten thousand branch points, so the number of execution paths through an application can be a very large.

Testing all those paths is a difficult task. (ahem.)

As a design decision, I left

as

Thinking the compiler would not even accept it, and if it did, it would fail on the first test efforts at this point, which it did.

Accomplished authors do it like this:

This compare is so much on the critical path that I wanted to break it on the first run in hopes of being *absolutely* sure this is the only way, the One True Way and,

The Official Documented: There is no Other Way way.

Many of the Collections require a compareTo() method to do their work.

Stack trace was of limited but real value, static constructor for class Alice prints:

"Globals! (Oh, the Horror) - Boris Alexeev"

Which showed up in the run log, so it's likely the ClassCastException did in fact occur during a Collections' attempt to do exactly what it said it would do.

I just need to avoid

later.

No room for that where this is going.

They don't use ropes to hang.

Hi cowboys,

I do not know who Boris Alexeev is but
the answer depends on whether you use generics or not.

When your class implements Comparable,
compareTo(Object boris) { }
would be the only way to override compareTo.

But when your class implements Comparable <Alice>
it should be
compareTo (Alice alexeev) { }

Frontal lobals, oh the horror!

Yours,
Bu.

I have jdk 1.2 or 1.3 or something, it does not have templated instantiations.

I.O.W. the slicing problem does not exist in Java ... so in that the only way the compiler has to separate overload signatures is by paramater list, the compiler authors have made arrangements to prevent losing the original class's definition.
[ May 20, 2007: Message edited by: Nicholas Jordan ]