Misaligned equals() and hashCode() break collections. Problems The least surprise principle violation
Contract violations
Mutable key issues
Duplicate hash codes
Debugging becomes hard
Poor hash distribution Solutions Avoid mutable keys
Use effective hashes
Test behavior carefully
Avoid redefining equal and hash
Honor the Bijection Context When you work with hashed collections like HashMap or HashSet, you should pay special attention to equals() and hashCode(). A mismatch or poor implementation can lead to unpredictable bugs. equals() method defines logical equality, while hashCode() determines an object’s bucket for faster access. When these two methods fail to align, collections lose their reliability, leading to poor performance or issues like duplicate entries caused by hash collections. The best solution is never to override the hash and equals and rely on object identity. This is what happens in the real world using the MAPPER). Whenever you get an external object you need to map it to your bijection correspondence and not create a brand new one. Once within your controlled system, rely on identity and forget equality issues. Sample Code Wrong class BrokenObject {
    private int value;

    public BrokenObject(int value) {
        this.value = value;
    }

    @Override
    public boolean equals(Object obj) {
        return true; // Always equal
    }

    @Override
    public int hashCode() {
        return super.hashCode(); // Uses default implementation
    }
} Right class FixedObject {
    private final int value;

    public FixedObject(int value) {
        this.value = value;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;
        if (obj == null || getClass() != obj.getClass()) return false;
        FixedObject that = (FixedObject) obj;
        return value == that.value;
    }

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

// This is the best solution

class CleanObject {
    private final int value;

    public FixedObject(int value) {
        this.value = value;
    }

    // - @Override
    // - public boolean equals(Object obj) {}

    // - @Override
    // - public int hashCode() { 
    }
} Detection [x]Semi-Automatic Automated linters and IDEs flag issues when you don't properly override equals() or hashCode(). Tags Premature Optimization Level [x]Intermediate AI Generation AI-generated code often missteps when generating equals() and hashCode(), especially for mutable objects. AI Detection AI tools can help fix this smell with minimal guidance. Try Them! Remember: AI Assistants make lots of mistakes Without Proper Instructions

With Specific Instructions



ChatGPT

ChatGPT



Claude

Claude



Perplexity

Perplexity



Copilot

Copilot



Gemini

Gemini Conclusion When you misuse equals() or hashCode(), collections misbehave. Stick to their contracts, use effective hashes, and avoid mutable keys. Related Reading https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxx https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxxiv https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-x-i7r34uj More Info https://hackernoon.com/is-it-crystal-clear-for-everybody-that-a-date-should-not-mutate-wuoy3z03?embedable=true Disclaimer: Code Smells are my opinion. Credits: Photo by frank mckenna on Unsplash “Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” Linus Torvalds https://hackernoon.com/400-thought-provoking-software-engineering-quotes?embedable=true This article is part of the CodeSmell Series: How to Find the Stinky Parts of your Code Misaligned equals() and hashCode() break collections. Misaligned equals() and hashCode() break collections. Problems The least surprise principle violation Contract violations Mutable key issues Duplicate hash codes Debugging becomes hard Poor hash distribution The least surprise principle violation Contract violations Mutable key issues Mutable Duplicate hash codes Debugging becomes hard Poor hash distribution Solutions Avoid mutable keys Use effective hashes Test behavior carefully Avoid redefining equal and hash Honor the Bijection Avoid mutable keys Use effective hashes Test behavior carefully Avoid redefining equal and hash Honor the Bijection Bijection Context When you work with hashed collections like HashMap or HashSet , you should pay special attention to equals() and hashCode() . HashMap HashSet equals() hashCode() A mismatch or poor implementation can lead to unpredictable bugs. mismatch equals() method defines logical equality, while hashCode() determines an object’s bucket for faster access. equals() hashCode() When these two methods fail to align, collections lose their reliability, leading to poor performance or issues like duplicate entries caused by hash collections. The best solution is never to override the hash and equals and rely on object identity. This is what happens in the real world using the MAPPER ). MAPPER Whenever you get an external object you need to map it to your bijection correspondence and not create a brand new one. Once within your controlled system, rely on identity and forget equality issues. Sample Code Wrong class BrokenObject {
    private int value;

    public BrokenObject(int value) {
        this.value = value;
    }

    @Override
    public boolean equals(Object obj) {
        return true; // Always equal
    }

    @Override
    public int hashCode() {
        return super.hashCode(); // Uses default implementation
    }
} class BrokenObject {
    private int value;

    public BrokenObject(int value) {
        this.value = value;
    }

    @Override
    public boolean equals(Object obj) {
        return true; // Always equal
    }

    @Override
    public int hashCode() {
        return super.hashCode(); // Uses default implementation
    }
} Right class FixedObject {
    private final int value;

    public FixedObject(int value) {
        this.value = value;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;
        if (obj == null || getClass() != obj.getClass()) return false;
        FixedObject that = (FixedObject) obj;
        return value == that.value;
    }

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

// This is the best solution

class CleanObject {
    private final int value;

    public FixedObject(int value) {
        this.value = value;
    }

    // - @Override
    // - public boolean equals(Object obj) {}

    // - @Override
    // - public int hashCode() { 
    }
} class FixedObject {
    private final int value;

    public FixedObject(int value) {
        this.value = value;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;
        if (obj == null || getClass() != obj.getClass()) return false;
        FixedObject that = (FixedObject) obj;
        return value == that.value;
    }

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

// This is the best solution

class CleanObject {
    private final int value;

    public FixedObject(int value) {
        this.value = value;
    }

    // - @Override
    // - public boolean equals(Object obj) {}

    // - @Override
    // - public int hashCode() { 
    }
} Detection [x]Semi-Automatic [x] Semi-Automatic [x] Automated linters and IDEs flag issues when you don't properly override equals() or hashCode() . equals() hashCode() Tags Premature Optimization Premature Optimization Level [x]Intermediate [x] Intermediate [x] AI Generation AI-generated code often missteps when generating equals() and hashCode() , especially for mutable objects. equals() hashCode() AI Detection AI tools can help fix this smell with minimal guidance. Try Them! Try Them! Remember: AI Assistants make lots of mistakes Remember: AI Assistants make lots of mistakes Without Proper Instructions

With Specific Instructions



ChatGPT

ChatGPT



Claude

Claude



Perplexity

Perplexity



Copilot

Copilot



Gemini

Gemini Without Proper Instructions

With Specific Instructions ChatGPT

ChatGPT Claude

Claude Perplexity

Perplexity Copilot

Copilot Gemini

Gemini Without Proper Instructions With Specific Instructions Without Proper Instructions Without Proper Instructions With Specific Instructions With Specific Instructions ChatGPT ChatGPT ChatGPT ChatGPT ChatGPT ChatGPT ChatGPT ChatGPT Claude Claude Claude Claude Claude Claude Claude Claude Perplexity Perplexity Perplexity Perplexity Perplexity Perplexity Perplexity Perplexity Copilot Copilot Copilot Copilot Copilot Copilot Copilot Copilot Gemini Gemini Gemini Gemini Gemini Gemini Gemini Gemini Conclusion When you misuse equals() or hashCode() , collections misbehave. equals() hashCode() Stick to their contracts, use effective hashes, and avoid mutable keys . mutable keys Related Reading https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxx https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxx https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxxiv https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxxiv https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-x-i7r34uj https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-x-i7r34uj More Info https://hackernoon.com/is-it-crystal-clear-for-everybody-that-a-date-should-not-mutate-wuoy3z03?embedable=true https://hackernoon.com/is-it-crystal-clear-for-everybody-that-a-date-should-not-mutate-wuoy3z03?embedable=true Disclaimer: Code Smells are my opinion. Disclaimer: Code Smells are my opinion . opinion Credits: Photo by frank mckenna on Unsplash Credits: Photo by frank mckenna on Unsplash frank mckenna Unsplash “Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” “Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” Linus Torvalds Linus Torvalds https://hackernoon.com/400-thought-provoking-software-engineering-quotes?embedable=true https://hackernoon.com/400-thought-provoking-software-engineering-quotes?embedable=true This article is part of the CodeSmell Series: How to Find the Stinky Parts of your Code This article is part of the CodeSmell Series: How to Find the Stinky Parts of your Code How to Find the Stinky Parts of your Code

This story contains new, firsthand information uncovered by the writer.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Code Smell 281 - When Equals and HashCodes Misbehave

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

10 Predictions About the Future of Finance

Code Smell 240 - Dead Store Code

Comparing XML and Compose Rendering Speed at Deep and Wide Nesting

"Don't Touch It, it Works" is Problematic in Engineering

How to Determine When Your Code Needs Refactoring

Improving the Code One Line at a Time

10 Predictions About the Future of Finance

Code Smell 240 - Dead Store Code

Comparing XML and Compose Rendering Speed at Deep and Wide Nesting

"Don't Touch It, it Works" is Problematic in Engineering

How to Determine When Your Code Needs Refactoring

Improving the Code One Line at a Time

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps