Have you ever heard of hashCode() and equals() in Java and the eternal discussions around this? And, you should know by now the implications of having a messed up relationship between hashCode and equals . You need to make sure that every time you implement a class with an equals(),  the hashCode() follows suit, right?

So, with that in mind, I will make sure that if I implement a Java bean, then whatever fields I involve in equals(), I will involve in hashCode() — JDK nowadays offers a method for computing hashcode via the Objects.hash(...). This makes it easy, right? And, as long as I do that with every bean, then if I ever extend one of these bean classes, all I have to care about is the fields in the subclass bean and making sure that I delegate to the superclass bean. If I do that, I will be fine.

At least, that’s how I used to think until I encountered the issue we are going to talk about below!

So, as I said, we start with a simple Java bean class — let’s consider a simple class that has just an int member — which we will involve in a both hashCode() and equals():

public class BaseClass {
 private int intValue; 

 @Override
 public boolean equals(Object o) {
  if (this == o) return true;
  if (!(o instanceof BaseClass)) return false;
  BaseClass baseClass = (BaseClass) o;
  return intValue == baseClass.intValue;
 }

 @Override
 public int hashCode() {
  return Objects.hash(intValue);
 }

 public int getIntValue() {
  return intValue;
 }

 public void setIntValue(int intValue) {
  this.intValue = intValue;
 }
}

Anything wrong with that? Nope, all good right?

Now, for the next step, I decided that I need to “specialize” this class — so, I extended it a bit and created the SpecializedChild class, which also adds a String member. Of course, being conscientious about the implications of hashCode/equals, I needed to make sure that I was using this member in both, as well as making sure I factor in the superclass’ hashCode/equals, which will look something like this:

public class SpecializedChild extends BaseClass {
 private String stringValue;

 @Override
 public boolean equals(Object o) {
  if (this == o) return true;
  if (!(o instanceof SpecializedChild)) return false;
  if (!super.equals(o)) return false;
  SpecializedChild that = (SpecializedChild) o;
  return Objects.equals(stringValue, that.stringValue);
 }

 @Override
 public int hashCode() {
  return Objects.hash(super.hashCode(), stringValue);
 }

 public String getStringValue() {
  return stringValue;
 }

 public void setStringValue(String stringValue) {
  this.stringValue = stringValue;
 }
}

See — this way, not only am I checking for equality against the newly introduced stringValue member, but I also allow the base class to do its own checks — as well as contribute in the hash calculations.

And, if you want, I can take the subclassing one step further and create the SubSpecializedChild, which adds another member and uses the same principle to check its own member and use it for hash computation as well as passing control to the base class:

public class SubSpecializedChild extends SpecializedChild {
 private Locale locale;

 @Override
 public boolean equals(Object o) {
  if (this == o) return true;
  if (!(o instanceof SubSpecializedChild)) return false;
  if (!super.equals(o)) return false;
  SubSpecializedChild that = (SubSpecializedChild) o;
  return Objects.equals(locale, that.locale);
 }

 @Override
 public int hashCode() {
  return Objects.hash(super.hashCode(), locale);
 }

 public Locale getLocale() {
  return locale;
 }

 public void setLocale(Locale locale) {
  this.locale = locale;
 }
}

Anything wrong so far with this approach?

I bet you are inclined to say “nope” just like I did! But, here’s the thing: the problem is exactly with subclassing and specifically with passing the control back to the superclass!

To prove it, I will now go through an exercise of refactoring and you can decide whether that int member in the BaseClass is irrelevant and does not contribute to the object “state,” so it doesn’t make sense to include it in the equals or the hash computations. Since that is the only member in that class, all I have to do is simply remove the equals()  and hashCode() implementation and rely on whatever Object class is offering — so I end up with this:

public class BaseClass {
 private int intValue; 

 public int getIntValue() {
  return intValue;
 }

 public void setIntValue(int intValue) {
  this.intValue = intValue;
 }
}

All right. Now, you say all is good and that it makes sense. However, now, you start noticing pretty soon that your equals() in the SubSpecialized class don’t work anymore! And, it is the same for hashCode(). To make matters even worse, your piece of code will look like this:

        SubSpecializedChild child1 = new SubSpecializedChild();
        child1.setLocale(new Locale(("en")));

        SubSpecializedChild child2 = new SubSpecializedChild();
        child2.setLocale(new Locale(("en")));

        Set set = new HashSet<>();

        System.out.println("EQUALS : " + child1.equals(child2));
        System.out.println("HASH 1 : " + child1.hashCode());
        System.out.println("HASH 2 : " + child2.hashCode());

        set.add(child1);
        set.add(child2);
        System.out.println("SET :");
        set.forEach(entry -> System.out.println("ENTRY : " + entry));

This used to work fine before and would generate a Set with a single entry. This now ends up with … two entries, even though they both store the same data!

The problem, as I said from the get go, is that now the call to hashCode() bubbles all the way up to Object.hashCode(), which is random at best. Now, despite all of your subclasses being so diligent about every single data member, it’s the superclass of the Object that screws it all up.

Moral of the story: in a hierarchy of Java beans, be careful with the base class. And, as much as it makes me sound like a broken record, write some unit tests for simple things like hashCode and equals — especially if you are going to use these in Set and Map instances, which make use of the object hashes.

More code for this can be found on GitHub.