What is the correct way of overriding hashCode () and equals () methods of persistent entity?

Question

I have a simple class Role:

@Entity
@Table (name = "ROLE")
public class Role implements Serializable {

    @Id
    @GeneratedValue
    private Integer id;
    @Column
    private String roleName;

    public Role () { }

    public Role (String roleName) {
        this.roleName = roleName;
    }

    public void setId (Integer id) {
        this.id = id;
    }

    public Integer getId () {
        return id;
    }

    public void setRoleName (String roleName) {
        this.roleName = roleName;
    }

    public String getRoleName () {
        return roleName;
    }
}

Now I want to override its methods equals and hashCode. My first suggestion is:

public boolean equals (Object obj) {
    if (obj instanceof Role) {
        return ((Role)obj).getRoleName ().equals (roleName);
    }
    return false;
}

public int hashCode () {
    return id; 
}

But when I create new Role object, its id is null. That's why I have some problem with hashCode method implementation. Now I can simply return roleName.hashCode () but what if roleName is not necessary field? I'm almost sure that it's not so difficult to make up more complicated example which can't be solved by returning hashCode of one of its fields.

So I'd like to see some links to related discussions or to hear your experience of solving this problem. Thanks!

Answer 1

Bauer and King's book Java Persistence with Hibernate advises against using the key field for equals and hashCode. They advise you should pick out what would be the object's business key fields (if there was no artificial key) and use those to test equality. So in this case if role name was not a necessary field you would find the fields that were necessary and use them in combination. In the case of the code you post where rolename is all you have besides the id, rolename would be what I'd go with.

Here's a quote from page 398:

We argue that essentially every entity class should have some business key, even if it includes all properties of the class (this would be appropriate for some immutable classes). The business key is what the user things of as uniquely identifying a particular record, whereas the surrogate key is what the application and database use.

Business key equality means that the equals() method compares only the properties that form the business key. This is a perfect solution that avoids all the problems presented earlier. The only downside is that it requires extra thought to identify the correct business key in the first place. This effort is required anyway; it's important to identify any unique keys if your database must ensure data integrity via constraint checking.

An easy way I use to construct an equals and hashcode method is to create a toString method that returns the values of the 'business key' fields, then use that in the equals() and hashCode() methods. CLARIFICATION: This is a lazy approach for when I am not concerned about performance (for instance, in rinky-dink internal webapps), if performance is expected to be an issue then write the methods yourself or use your IDE's code generation facilities.

Answer 2

I'm sorry to jump in late with criticism, but nobody else has mentioned it and .。 Possibly two, actually.

First, others have mentioned how to handle the possibility of null, but one critical element of a good hashcode() and equals() method pair is that they must obey the contract, and your code above does not do this.

The contract is that , but in your class above, the fields id and roleName are independent. ，但在上面的类中，字段 id 和 roleName 是独立的。

This is fatally flawed practice: you could easily have two objects with the same roleName value, but different id values.

The practice is to use the same fields to generate the hashcode value as are used by the equals() method, and in the same order. Below is my replacement for your hashcode method:

public int hashCode () {
    return ((roleName==null) ? 0 : roleName.hashcode()); 
}

Note: I don't know what you intended by the use of the id field as hashcode, or what you meant to do with the id field. I see from the annotation that it's generated, but it's externally generated, so the class as written fails to fulfill the contract.

If for some reason you find yourself in a situation where this class is exclusively managed by another which faithfully generates "id" values for roleNames which do fulfill the contract, you wouldn't have a functionality problem, but it would still be bad practice, or at least have what people refer to as a "code smell". Besides the fact that there's nothing in the class definition to guarantee that the class is only usable in that way, . 。

That doesn't mean you couldn't use a guaranteed-equal-for-equal-rolename-values identifier as the hashcode, but they're not conceptually the same, so at the very least, you should have a block of comment to explain your departure from expected practice.

And as a good general rule, if you find yourself having to do that, you've probably made a design error. Not always, but probably. One reason for that? People don't always read comments, so even if you create a perfectly functioning system, over time, someone will "misuse" your class and cause problems.

Having the class itself manage the generation of hashcode values avoids that. And you could still save and make available the externally generated id, for whatever purpose you use it.

Answer 3

The business key of an object may require its parent (or another one-to-one or many-to-one) relation. In those cases, calling equals() or hashcode() could result in a database hit. Aside from performance, if the session is closed that will cause an error. I mostly gave up trying to use business keys; I use the primary id and avoid using un-saved entities in maps and sets. Has worked well so far but it probably depends on the app (watch out when saving multiple children through the parent cascade). Occasionally, I'll use a separate meaningless key field that's a uuid auto-generated in the constructor or by the object creator.

Answer 4

Please find below simple instructions how to create hashCode, equals and toString methods using Apache commons builders.

hashCode

1. If two objects are equal according to the equals() method, they must have the same hashCode() value
2. It is possible that two distinct objects could have the same hashCode().
3. Please use unique Business ID for the hashCode creation (it is mean that you should use some unique property that represent business entity, for example, name)
4. Hibernate Entity: please do NOT use Hibernate id for the hashCode creation

5. You may call for .appendSuper(super.hashCode()) in case your class is subclass

   \n@Override \npublic int hashCode() {\n    return new HashCodeBuilder()\n            .append(getName()) \n            .toHashCode(); \n} \n

equals

1. Please compare Business ID (it is mean that you should use some unique property that represent business entity, for example, name)
2. Hibernate Entity: please do NOT compare Hibernate id
3. Hibernate Entity: use getters when you access the other object field to let to Hibernate to load the property

4. You may call for .appendSuper(super.equals(other)) in case your class is subclass

   \n@Override \npublic boolean equals(final Object other) {\n    if (this == other)\n        return true;\n    if (!(other instanceof TreeNode)) \n        return false;\n    TreeNode castOther = (TreeNode) other; \n    return new EqualsBuilder()\n            .append(getName(), castOther.getName()) \n            .isEquals(); \n} \n

toString

1. Please ensure that toString will not throw NullPointerException.

2. You may call for .appendSuper(super.toString()) in case your class is subclass

   \n@Override \npublic String toString() {\n    return new ToStringBuilder(this)\n            .append("Name", getName()) \n            .toString(); \n} \n

Answer 5

知道何时覆盖 hashCode 和 equals 不是一件容易的事，还有另一个讨论，您在此处提供示例和文档链接，在 Java 中覆盖 equals 和 hashCode 时应考虑哪些问题？

Answer 6

As already mentioned you have to use a business key to implement equal and hashCode. Additionally you have to make your equals and hashCode implementation null-safe or add not null contraints (and invariant checks into your code) to ensure that the business key is never null.

I suppose adding constraints is the right approach for your problem. Otherwise Role instances without names would be allowed and all these physical instances would be considered equal.

Answer 7

I use Lombok on my project here's a tally of the rules that apply to JPA entities I moved the ones specific for equals() and hashCode() to the top

Rules for building entity classes

When creating, make sure of the following

• EqualsHashCode should only be done on "business keys"

• Composite keys are generally business keys. so they must not be EqualsHashCode.Exclude

• EqualsHashCode.Exclude on "surrogate keys" / "technical IDs" such as generated IDs, Version, audit fields, values that get updated by @PrePersist or @PreUpdate

• ManyToOne must have EqualsHashCode.Exclude and ToString.Exclude to prevent stack overflow

• ManyToOne must have a corresponding EqualsHashCode.Include and ToString.Include to get the ID field of the referenced object. The method must be suffixed with Id and should not start with get

---

• @Entity class names must be singular. The @Repository class names would be plural.
• @Entity must have @Data
• @Entity must be Serializable
• @Entity must have @NoArgsConstructor if a constructor is provided
• Composite keys must have @Data
• @OneToMany must have cascadeType=Cascade.ALL
• @OneToMany must have mappedBy
• @OneToMany must have orphanRemoval=true
• @OneToMany must be a Set
• ManyToOne must have optional=false
• ManyToOne must have a @JoinColumn

What constitutes as business keys?

Use the analogy of two equivalent deck of cards that are soiled and are shuffled together. A collection would be a deck that should contain cards that have a uniquely identifiable value.

• The business key would be the suit, the number even the card back. These uniquely identify the value of the card.

• The soil pattern provided it is only in the face of the card is not relevant. As such it is not part of the business key.

• The physical existence of the card itself is also not part of the business key. This is similar to a generated private key for the card. This is also referred to as a surrogate key or technical ID.