equals(), hashCode() & toString() Contracts

public class Point {
    int x, y;
    // No overrides
}

Point p1 = new Point(); p1.x = 1; p1.y = 2;
Point p2 = new Point(); p2.x = 1; p2.y = 2;
System.out.println(p1.equals(p2));  // false! Default equals() is reference equality, despite identical field values

Common follow-ups: What's the difference between == and .equals() for object references in Java?;Why does Object's default hashCode() typically use memory address rather than field values?

public class CaseInsensitiveString {
    private final String value;
    public boolean equals(Object o) {
        if (o instanceof String s) return value.equalsIgnoreCase(s);  // BROKEN: violates symmetry!
        if (o instanceof CaseInsensitiveString c) return value.equalsIgnoreCase(c.value);
        return false;
    }
    // "ABC".equals(myCaseInsensitiveString) uses String's equals(), which returns false
    // but myCaseInsensitiveString.equals("ABC") returns true -- SYMMETRY VIOLATED

Common follow-ups: Why is symmetry particularly easy to accidentally violate when comparing across different but related classes?;What specific bugs manifest in HashMap/HashSet when the transitivity property is violated?

// getClass() approach: strict, safe, but a subclass can NEVER equal its superclass
public boolean equals(Object o) {
    if (o == null || getClass() != o.getClass()) return false;
    Point p = (Point) o;
    return x == p.x && y == p.y;
}

// instanceof approach: more flexible, but risks violating transitivity if subclasses add fields
public boolean equals(Object o) {
    if (!(o instanceof Point p)) return false;
    return x == p.x && y == p.y;  // ColorPoint could pass this using only inherited x/y!
}

Common follow-ups: Why does Effective Java specifically recommend favoring composition over inheritance to avoid this equals() dilemma entirely?;What are the practical consequences of getClass()-based equals() when working with proxies or ORM-generated subclasses (like Hibernate entities)?

public class Person {
    private final String name;
    private final String email;  // nullable

    @Override
    public boolean equals(Object o) {
        if (!(o instanceof Person p)) return false;
        return Objects.equals(name, p.name) && Objects.equals(email, p.email);  // null-safe
    }

    @Override
    public int hashCode() {
        return Objects.hash(name, email);  // handles null fields automatically
    }
}

Common follow-ups: What's the performance overhead of Objects.hash()'s varargs array creation compared to manually combining hash codes?;How do IDE-generated equals()/hashCode() methods typically differ from using Objects.equals()/hash()?

public class BadKey {
    private final String id;
    public BadKey(String id) { this.id = id; }

    @Override
    public boolean equals(Object o) {  // overridden
        return o instanceof BadKey k && id.equals(k.id);
    }
    // hashCode() NOT overridden -- still uses Object's identity-based default!
}

Map<BadKey, String> map = new HashMap<>();
map.put(new BadKey("x"), "value");
System.out.println(map.get(new BadKey("x")));  // prints null! Different hashCode() despite equals() returning true

Common follow-ups: Why does a HashMap check hashCode() before ever calling equals(), rather than just calling equals() directly against every entry?;How would you write a unit test specifically to catch an equals()/hashCode() contract violation like this?

public class Point {
    private final int x, y;

    @Override
    public String toString() {
        return "Point{x=" + x + ", y=" + y + "}";
    }
}

System.out.println(new Point(3, 4));
// Default would print: Point@7852e922 (unhelpful)
// Custom prints: Point{x=3, y=4} (immediately useful for debugging)

Common follow-ups: How do IDEs and tools like Lombok's @ToString help automate generating a reasonable toString() implementation?;What are the risks of including sensitive data (like a password field) in a toString() implementation, especially given logging frameworks might capture it?

public record Point(int x, int y) {}
// Automatically gets: equals() comparing x and y, hashCode() combining them, and
// toString() producing "Point[x=3, y=4]" -- all without writing a single line of boilerplate

public record Data(int[] values) {}
Data d1 = new Data(new int[]{1,2,3});
Data d2 = new Data(new int[]{1,2,3});
System.out.println(d1.equals(d2));  // FALSE! Array components compare by reference, not content, by default

Common follow-ups: Why did the record specification choose reference-based comparison for array components rather than automatically using Arrays.equals()?;How would you override just equals()/hashCode() for a record while keeping the other auto-generated members?

Integer a = 100, b = 100;
System.out.println(a == b);  // true, coincidentally -- both within the cached range (-128 to 127)

Integer c = 200, d = 200;
System.out.println(c == d);  // false! Outside the cache range, two genuinely distinct Integer objects

System.out.println(c.equals(d));  // true, correctly compares actual values regardless of caching

Common follow-ups: Why does Java cache small Integer values in the first place, and can this caching range be configured?;What's the safest general practice for comparing boxed numeric types to avoid this pitfall entirely?

public class MutablePoint {
    private int x, y;  // mutable! setters allow changing after construction
    public void setX(int x) { this.x = x; }

    @Override
    public int hashCode() { return Objects.hash(x, y); }
    // equals() omitted for brevity, also compares x, y
}

Set<MutablePoint> set = new HashSet<>();
MutablePoint p = new MutablePoint();  // x=0, y=0
set.add(p);
p.setX(99);  // mutated AFTER insertion -- hash code effectively changed, but set doesn't know!
System.out.println(set.contains(p));  // often false! Lookup now targets a DIFFERENT bucket than where p actually sits

Common follow-ups: What defensive coding practices help prevent accidentally using mutable objects as hash-based collection keys?;How does this specific risk relate to the broader design principle favoring immutability for value-like classes?

// Using EqualsVerifier (a popular open-source testing library) for comprehensive automatic verification
import nl.jqno.equalsverifier.EqualsVerifier;

@Test
void equalsContract() {
    EqualsVerifier.forClass(Point.class).verify();
    // automatically checks reflexivity, symmetry, transitivity, null-safety,
    // hashCode consistency, and more -- catches subtle bugs a hand-written test might miss
}

Common follow-ups: What specific configuration options does EqualsVerifier provide for classes with intentionally non-standard equals() behavior (like inheritance-based comparison)?;How would you write these contract verification tests manually without a library, and what's the risk of missing an edge case that way?