(Hopefully) The Final Article About Equals and HashCode for JPA Entities With DB-Generated IDs

1. Gain insights about default equals() and hashCode() implementations;
2. Discover issues you might encounter using common equals() and hashCode() implementations found on the internet;
3. Learn a lot of interesting things about proxies in Hibernate.

Should We Override Equals and HashCode at All?

public interface StudentRepository extends JpaRepository<Student, Long> { 
  Set<Student> findByAverageGradeLessThan(Short averageGrade); 
  Set<Student> findByNameStartsWithIgnoreCase(String name); 
}

@Service 

public class StudentService { 
 
  private final StudentRepository studentRepository; 
 
  public StudentService(StudentRepository studentRepository) { 
    this.studentRepository = studentRepository; 
  } 
 
  @Transactional 
  public Set<Student> getStudentsWithNameStartsWith(String letter) { 
    return studentRepository.findByNameStartsWithIgnoreCase(letter); 
  } 
 
  @Transactional 
  public Set<Student> getStudentsWithAverageGradeLessThan(Short averageGrade) { 
    return studentRepository.findByAverageGradeLessThan(averageGrade); 
  } 
} 

So, the controller with the corresponding REST endpoint will look like this: 

@RestController 
@RequestMapping("/students") 
public class StudentController { 
  private final StudentService studentService; 
 
  public StudentController(StudentService studentService) { 
    this.studentService = studentService; 
  } 
 
  @GetMapping(value = "/name-and-grade") 
  public Set<Student> getStudentsWithNameStartsWithAndGradeLessThan(
             @RequestParam(name = "prefix") String prefix,
             @RequestParam(name = "grade") Short grade) { 
    Set<Student> students = studentService.getStudentsWithNameStartsWith(prefix); 
    students.retainAll(studentService.getStudentsWithAverageGradeLessThan(grade)); 
    return students; 
  } 
}

Please note that we have disabled the "open session in view."  Firstly, long database sessions have a negative impact on throughput, thereby affecting the performance of the application. Secondly, we do not have control over additional queries, which can lead to the N+1 query problem. Lastly, all additional queries open transactions in auto-commit mode, causing transaction logs to be flushed with each statement, negatively impacting database performance once again. Therefore, we do not have a transaction open all the time, so we have to open it ourselves when needed.

1. Avoid using entities within hash-based collections throughout the entire project;
2. If you use hash-based collections, they should exist within the transaction where you retrieved the entities;
3. Do not mix entities from different transactions into the same hash-based collection;
4. Do not compare entities via  equals().

Let Me Google/ChatGPT It for You

Stack Overflow and Vlad Mihalcea Implementations

ChatGPT and Thorben Janssen Implementations

Results of Research

Making Proxies Great Again

Hibernate offers a powerful proxy mechanism that effectively reduces load to a database by fetching data only when necessary. It is essential to understand that we may interact exclusively with proxy objects, solely with entities, or even with both simultaneously in specific scenarios.

Let's test the current implementations when a proxy object comes into play. For example, declare proxy and non-proxy objects belonging to the same database record. Then, add them to a HashSet and ensure that the size of the HashSet is equal to 1.

@Test 
void equalsAndHashCodeTest() { 
  studentRepository.save(new Student()); 
 
  Student student = studentRepository.findById(1L).orElseThrow(); 
  Student proxy = studentRepository.getReferenceById(1L); 
 
  Set<Student> students = new HashSet<>(); 
 
  students.add(student); 
  students.add(proxy); 
 
  Assertions.assertEquals(1, students.size()); 
}

The test failed. However, the reason for this was a LazyInitializationException, not the collection's size.

Note: Later on, we'll use the term "initialization" to refer to accessing the database, loading field values, and setting it to the proxy.

In the considered implementations, the equals() method directly accessed the id field instead of using a getter method. Furthermore, none of the methods were declared as final. When using Hibernate, a proxy object is initialized whenever a non-final method is called (getId() is an exception to the rule). As a result, using non-final equals() and hashCode() methods can cause unintended proxy initialization and additional hits to the database.

To fix this, we need to access the id through a getter method and declare the methods as final:

Excellent! Now we can execute the test without an open transaction. Unfortunately, the test failed once again. This time the reason is the difference between actual and expected collection sizes:

When dealing with a proxy object, the getClass() method returns a different value than the original class. Consequently, with the current hashCode() implementation, we get different hash codes for proxy and non-proxy objects. Therefore, java placed them in different buckets inside a hash-based collection and didn’t even compare them for equality. That is why the collection size has become equal to 2.

We can use the Hibernate.getClass() method to address this issue. The documentation for this method states, "Get the true, underlying class of a proxied entity". By using this method, we can ensure accurate hash codes generation and equality comparisons in scenarios involving proxies and non-proxy objects.

The test fails once more! This time, again, due to a LazyInitializationException.

After adding the proxy to HashSet, the following call chain occurs:

The AbstractLazyInitializer.initialize() method leads to a select query to the database. It looks like we missed something. Let's take another look at the Hibernate.getClass() method documentation:

There it is! This side-effect is exactly what we have encountered here!

Before Hibernate version 5.6, we could use the HibernateProxyHelper class and its getClassWithoutInitializingProxy() method instead of Hibernate.getClass(). Since Hibernate version 6, we need to use the following approach to avoid proxy initialization:

HibernateProxy.getHibernateLazyInitializer().getPersistentClass()

Consequently, the implementation of equals() and hashCode() methods will appear as follows:

And now the test is a breeze!

The Best Way To Implement Equals and Hashcode for JPA Entities...So Far

@Override 
public final boolean equals(Object o) { 
  if (this == o) return true; 
  if (o == null) return false; 
  Class<?> oEffectiveClass = o instanceof HibernateProxy ? ((HibernateProxy) o).getHibernateLazyInitializer().getPersistentClass() : o.getClass(); 
  Class<?> thisEffectiveClass = this instanceof HibernateProxy ? ((HibernateProxy) this).getHibernateLazyInitializer().getPersistentClass() : this.getClass(); 
  if (thisEffectiveClass != oEffectiveClass) return false; 
  Student student = (Student) o; 
  return getId() != null && Objects.equals(getId(), student.getId()); 
} 
 
@Override 
public final int hashCode() { 
 return this instanceof HibernateProxy 
 	? ((HibernateProxy) this).getHibernateLazyInitializer().getPersistentClass().hashCode() 
	: getClass().hashCode(); 
}

With this implementation, you won't encounter problems when comparing: 

1. Newly created objects not yet associated with the database; 
2. Proxy and non-proxy objects associated with the same database record; 
3. Two proxy objects associated with the same database record; 
4. Objects inherited from a class where the equals() and hashCode() implementations are defined; 
5. Two identical objects from different sessions (obtained from different transactions).