转自[Java Notes]http://leepoint.net/notes-java/data/expressions/22compareobjects.html
a == b , a != b |
Equal values | Compares references, not values. The use of == with object references is generally limited to the following:
|
a.equals(b) |
N/A | Compares values for equality. Because this method is defined in the Object class, from which all other classes are derived, it's automatically defined for every class. However, it doesn't perform an intelligent comparison for most classes unless the class overrides it. It has been defined in a meaningful way for most Java core classes. If it's not defined for a (user) class, it behaves the same as ==. It turns out that defining |
a.compareTo(b) |
N/A | Comparable interface. Compares values and returns an int which tells if the values compare less than, equal, or greater than. If your class objects have a natural order, implement the Comparable<T> interface and define this method. All Java classes that have a natural ordering implement this (String, Double, BigInteger, ...). |
compare(a, b) |
N/A | Comparator interface. Compares values of two objects. This is implemented as part of the Comparator<T> interface, and the typical use is to define one or more small utility classes that implement this, to pass to methods such as sort() or for use by sorting data structures such as TreeMap and TreeSet. You might want to create a Comparator object for the following.
If your class objects have one natural sorting order, you may not need this. |
==
and !=
OperatorsThe two operators that can be used with object references are comparing for equality (==
) and inequality (!=
). These operators compare two values to see if they refer to the same object . Although this comparison is very fast, it is often not what you want.
Usually you want to know if the objects have the same value , and not whether two objects are a reference to the same object. For example,
if (name == "Mickey Mouse") // Legal, but ALMOST SURELY WRONG
This is true only if name
is a reference to the same object that "Mickey Mouse"
refers to. This will be false if the String in name
was read from input or computed (by putting strings together or taking the substring), even though name
really does have exactly those characters in it.
Many classes (eg, String
) define the equals()
method to compare the values of objects.
equals()
MethodUse the equals()
method to compare object values. The equals()
method returns a boolean value. The previous example can be fixed by writing:
if (name.equals ("Mickey Mouse")) // Compares values, not refererences.
Because the equals()
method makes a == test first, it can be fairly fast when the objects are identical. It only compares the values if the two references are not identical.
The equals
method and ==
and !=
operators test for equality/inequality, but do not provide a way to test for relative values. Some classes (eg, String and other classes with a natural ordering) implement the Comparable<T> interface, which defines a compareTo
method. You will want to implement Comparable<T> in your class if you want to use it with Collections.sort() or Arrays.sort() methods.
As described in the table above on compare()
, you can create Comparators to sort any arbitrary way for any class. For example, the String class defines the CASE_INSENSITIVE_ORDER comparator.
Overriding hashCode()
. The hashCode()
method of a class is used for hashing in library data structures such as HashSet
and HashMap
. If you override equals()
, you should override hashCode()
or your class will not work correctly in these (and some other) data structures.
The general advice is that if a.equals(b)
is true, then a.compareTo(b) == 0
should also be true. Curiously, BigDecimal
violates this. Look at the Java API documentation for an explanation of the difference. This seems wrong, although their implementation has some plausibiliby.
String has the specialized equalsIgnoreCase()
and compareToIgnoreCase()
. String also supplies the constant String.CASE_INSENSITIVE_ORDER
Comparator.
Comparing objects is somewhat awkward, so a === operator has been proposed. One proposal is that a === b
would be the same as ((a == b) || ((a != null) && a.equals(b)))
equals()
with Objects
==
to see if they are the
same object , or
equals()
to see if they may be a different object, but have the
same value . This kind of error can be very hard to find.