.equals() VS ==

Just a small post to tell you an other story of my daily learning of Java programming.

Always use .equals() method instead of ==

In our application, I was always comparing objects using ==. All worked fine until …. we decided to use a database to persist our objects across application launches and to avoid OutOfMemoryError. Why ???

The answer is easy, each time an object is retrieved from the database, we create a NEW Java object initialized with the values stored in the database. Thus, the == operator is no more valid between to different Java objects representing the same “conceptual object”.

After overriding the equals and hashCode methos for my persitent objects I had to refactor all my lines of code to replace all == by equals method ;o)


8 thoughts on “.equals() VS ==

  1. Not to be unpleasant, but this is kind of Java 101 (well at least to pretend to be a correct java developer).

    Also check that you indeed implemented equals correctly where this must always be true:
    reflexivity: x.equals(x) is true
    symmetry: if x.equals(y) then y.equals(x)
    transitivity: if x.equals(y) and y.equals(z) then x.equals(z)

    This can seem stupid but very often you can find some cases where one of this rule is broken (e.g. if you have derived classes)

  2. Hi Guillaume,

    I don’t know Java 101, what is it exactly ?

    I agree with you on the fact that all “correct” Java developer” must always use .equals() !!!

    I had to encounter a concrete case when == results in lot of refactoring to definitely have in mind to always use .equals !!!

    Does it mean that I am a correct Java developer now ?? ;o)


  3. Java 101 means it’s part of the basics (although yeah, not really beginners basics but as soon as you get a bit advanced, that’s a thing you should know).
    So yeah I guess you’re on the good path at least, as I can’t judge you on the rest ;)

  4. I would suggest that you use == when you mean “is identical”; that is, when you really want to make sure that two references point to the same object. If you really mean “is equal”, then use equals().

    The rule is (should be), never use == to test equality.

    FWIW, some relational persistence mapping solutions do give you back identical objects…

  5. Manu,

    As Wayne suggests, you can’t always reduce what’s best to simple absolute rules. Certainly if you want to check for equality instead of identity you better use the right operator; keep in mind that == is exceedingly cheap and equals can be shockingly expensive. It’s quite tricky to implement equals properly and quite common to forget to override hashCode. Also, once a base class overrides equals and hashCode, it becomes important that derived classes override it. A nasty aspect of objects for which the hash code changes depending on the state of the object is that it’s dangerous to use them as keys of an ordinary map or as elements in a set, if that set’s implementation used the hash code.

  6. Pingback: java programming lesson

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s