Not all equals methods are created equal
summary
Shows concrete bugs: an IDE can generate an equals with the wrong signature (equals(Object) signature), mutable fields that change hashCode break HashSet lookups, and using getClass vs instanceof causes Liskov and mocking tools to fail. Adding state in a subclass creates symmetry/transitivity failures unless the canEqual pattern is used. Demonstrates EqualsVerifier as a one-line test that flags each specific failure (and sometimes needs manual helpers for recursive types like java.sql.Date).
AI-written summary · about
chapters (9)
- 0:00Start
- 2:08Transitivity
- 3:13Three Kinds of Equals Tests in Projects
- 6:52Consistency
- 8:41Liskov Substitution Principle
- 13:49Transitivity Issue
- 18:19Make Your Equals and Hashcode Method Final
- 18:47Concluding
- 26:23How Does ecos Verifier Work with Objects That Have Custom Objects inside of Them
related talks
37mEffective Java with Groovy & Kotlin
28m11 Crazy Things I Didn't Know You Could Do With Java Until I Got...
01h 26mEqual Rights for Tests
43mFrom Effective Java to Effective Kotlin
45mTesting the untestable PART II – patterns, use cases and practices
50mModern Java Puzzlers
51mWhen Types are Not Enough
29mSame same but different: A Comparative Analysis of Static Type Checkers in Erlang