equals() and hashcode() oh my!

While communicating with a colleague today, I was reminded today about how painful explaining equals() and hashcode() to new Java developers can be. What’s particularly frustrating is that it’s not really a Java issue. I remember learning all about the ins and outs of equality and hash in Smalltalk, and then struggling to help others understand. It’s one of those classic computer-sciency problems that I used to use as a discussion point when interviewing potential co-op hires; I don’t recall ever finding a student who really understood it, but it helped me sort out the ones who could at least start solving a problem. When it comes down to it, understanding how best to implement these two methods is just plain hard.

Since this continues to be laboured about in numerous forums, I really don’t want to get into the specifics of how these methods should be implemented. For what it’s worth, I can’t remember the last time I actually implemented these methods. I’ve been building enterprise applications for many years now, and I can’t honestly remember actually needing these methods in my domain objects. That’s probably not an accurate reflection of reality; I probably just don’t remember implementing them.

I’m not sure what the point of this posting is. Maybe, it’s that—despite having lots of great infrastructure, frameworks, and APIs—there are just some fundamental concepts you really need to understand in order to do good stuff. Or maybe I’m just mumbling…

This entry was posted in Uncategorized. Bookmark the permalink.

6 Responses to equals() and hashcode() oh my!

  1. Rafael Chaves says:

    > I’ve been building enterprise applications for
    > many years now, and I can’t honestly remember
    > actually needing these methods in my domain objects

    I take you hadn’t been using Hibernate for those enterprise applications.

    With Hibernate (and I guess any other ORM frameworks out there), you are expected to implement equals and hash code for *every* domain object that has to be persisted, and you are not supposed to use a surrogate key.


  2. Rafael Chaves says:

    I meant: “you are not supposed to use a surrogate key” in the implementation of equals and hashcode.

  3. Neil Bartlett says:

    Maybe the point is that Eclipse will generate these methods for you?

  4. Wayne Beaton says:

    Rafael: Nope, I’ve never used Hibernate. I used TopLink years ago, but I believe I heard that they changed it so that the framework no longer depends on your implementations of the methods.

    Neil: Yep, Eclipse will generate these for you, but it does let you decide what fields to include in the implementations; you need to be careful what fields you choose.

  5. Neil Bartlett says:

    To be honest this is the sort of thing that should be handled by the VM or the compiler. I’d like to see a field-level annotation to specify whether each field should be included/excluded. Then nobody would ever have to write .equals() or .hashCode() methods again — it’s just too error-prone!

  6. Wayne Beaton says:

    But you still have to indicate what fields need to be included/excluded. That’s the hard part to get right.

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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s