Equality comparison: One way for primitives, Four ways for objects
| Comparison | Primitives | Objects |
|---|
a == b, a != b | Equal values |
Compares references, not values. The use of == with object references is generally limited to the following:
- Comparing to see if a reference is null.
- Comparing two enum values. This works because there is only
one object for each enum constant.
- You want to know if two references are to the same object
|
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 equals() isn't trivial;
in fact it's moderately hard to get it right, especially in the
case of subclasses. The best treatment of the issues
is in Horstmann's Core Java Vol 1.
[TODO: Add explanation and example]
|
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.
- Multiple comparisons. To provide several different ways to sort something. For example,
you might want to sort a Person class by name, ID, age, height, ...
You would define a Comparator for each of these to pass to the
sort()
method.
- System class. To provide comparison methods for classes that you have no control over. For example,
you could define a Comparator for Strings that compared them by length.
- Strategy pattern. To implement a strategy pattern, which is a situation where you
want to represent an algorithm as an object that you can pass as
a parameter, save in a data structure, etc.
If your class objects have one natural sorting order, you may not need this.
|
Comparing Object references with the == and != Operators
The 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.
Comparing Object values with the equals() Method
Use 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 references.
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.
Other comparisons - Comparable<T> interface
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.
Defining a Comparator object
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.
If you override equals, you should also override hashCode()
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.
Shouldn't .equals and .compareTo produce same result?
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 plausibility.
Other comparison methods
String has the specialized
equalsIgnoreCase() and
compareToIgnoreCase().
String also supplies the constant
String.CASE_INSENSITIVE_ORDER Comparator.
The === operator (Doesn't exist - yet?)
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)))
Common Errors
- Using == instead of
equals() with Objects
- When you want to compare objects, you need to know whether you should
use
== 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.
References
