Java equals, hashCode and toString contracts

Two Point objects for (3, 4) describe the same point, yet with the methods every class inherits from Object a HashSet keeps both of them, 2 elements, and a set that holds one says it does not contain the other. Those methods treat every object as unique: equals is true only for the very same object, hashCode gives each object a number of its own, and toString prints the class name, an @ and a hexadecimal number.

When your objects stand for values, such as a point, a seat on a train or an amount of money, you override equals so that equal values compare equal, and then hashCode as well: the Object documentation makes equal hash codeshash code: The int that hashCode returns for an object. A hash table uses it to pick a bucket, so objects that equals calls equal must return the same hash code; unequal objects may share one, which only slows the table down. for equal objects a contract, and HashSet and HashMap rely on it without checking. This lesson writes all three methods, breaks each one in a recorded run, and counts what a poor hash code costs a HashMap: 501,499 calls to equals for 1,000 lookups.

Object treats every object as unique, so value classes override equals

Object.equals returns true only when both references lead to the very same object. Its documentation calls this the most discriminating equivalence relationequivalence relation: A relation that is reflexive (x equals x), symmetric (if x equals y, then y equals x) and transitive (if x equals y and y equals z, then x equals z). The Object documentation requires equals to be one. possible: every object is equal only to itself. Object.hashCode returns a number tied to the object’s identity, its identity hash codeidentity hash code: The hash code Object.hashCode gives an object whose class does not override it, and System.identityHashCode gives any object: a number tied to that one object rather than to its field values.; as far as is reasonably practical, distinct objects get distinct numbers. That is the right behaviour for objects with an identity of their own, such as an open file or a running thread, and the wrong one for values.

Every example of this lesson is a small program in a folder of its own: a Main.java compact source file and the classes it uses, each in a file of its own. java points/Main.java compiles Main.java and the classes it needs from the same folder, then runs it; the launcher has run programs made of several source files since JDK 22 (JEP 458).

Here are three classes for a point, each tried the way a HashSet uses them. PlainPoint overrides nothing, EqualsOnlyPoint overrides only equals, and Point overrides both methods:

// Two objects for the point (3, 4) from each class, checked the way a HashSet uses them.
void main() {
    IO.println("class            equals  same hash  set size  contains");
    report("PlainPoint", new PlainPoint(3, 4), new PlainPoint(3, 4));
    report("EqualsOnlyPoint", new EqualsOnlyPoint(3, 4), new EqualsOnlyPoint(3, 4));
    report("Point", new Point(3, 4), new Point(3, 4));
}

void report(String name, Object a, Object b) {
    Set<Object> both = new HashSet<>();
    both.add(a);
    both.add(b);                        // a second element, unless the set decides that b equals a
    Set<Object> onlyA = new HashSet<>();
    onlyA.add(a);
    IO.println("%-16s %-7s %-10s %-9d %s".formatted(
            name, a.equals(b), a.hashCode() == b.hashCode(), both.size(), onlyA.contains(b)));
}

/** A point that keeps what Object gives every class: equals means "the very same object". */
final class PlainPoint {
    private final int x;
    private final int y;

    PlainPoint(int x, int y) {
        this.x = x;
        this.y = y;
    }
}

/** Overrides equals but not hashCode: equal points still get the hash codes of two different objects. */
final class EqualsOnlyPoint {
    private final int x;
    private final int y;

    EqualsOnlyPoint(int x, int y) {
        this.x = x;
        this.y = y;
    }

    @Override
    public boolean equals(Object other) {
        return other instanceof EqualsOnlyPoint p && x == p.x && y == p.y;
    }
}

import java.util.Objects;

/** equals and hashCode, both computed from the same two fields. */
final class Point {
    private final int x;
    private final int y;

    Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    @Override
    public boolean equals(Object other) {
        return other instanceof Point p && x == p.x && y == p.y;
    }

    @Override
    public int hashCode() {
        return Objects.hash(x, y);
    }
}

from session import run

# Main.java uses the three point classes, so the launcher compiles their files from points/ too.
# Then javac with its "overrides" lint, which warns about an equals without a hashCode.
run("""
java points/Main.java
javac -Xlint:overrides -d build points/EqualsOnlyPoint.java
""")

# openjdk version "25.0.4.1" LTS
$ java points/Main.java
class            equals  same hash  set size  contains
PlainPoint       false   false      2         false
EqualsOnlyPoint  true    false      2         false
Point            true    true       1         true
$ javac -Xlint:overrides -d build points/EqualsOnlyPoint.java
points/EqualsOnlyPoint.java:2: warning: [overrides] Class EqualsOnlyPoint overrides equals, but neither it nor any superclass overrides hashCode method
final class EqualsOnlyPoint {
      ^
1 warning

Read the table one row at a time:

• PlainPoint behaves as Object intends. The two objects are different, so the set keeps both and does not contain the second one. For a value that is wrong, but at least it is consistent.
• EqualsOnlyPoint is the dangerous one. equals now says true, yet the set still holds two elements and contains still says false. The set never asked equals at all, because the two hash codes differ.
• Point gives equal objects equal hash codes, so the set keeps one element and finds it.

The middle row is a broken contract, and running the program reports nothing: it compiles, runs and prints wrong answers. The second command shows the one place that can warn you. Compiled by javac with the overrides lint switched on (-Xlint:overrides, or every lint with -Xlint:all), EqualsOnlyPoint gets a warning that it overrides equals but not hashCode. Build tools pass such options to javac, so it is worth turning on.

A hash table asks hashCode first and equals only inside one bucket

A HashSet is backed by a HashMap that keeps its elements as keys. To look a key up, the map calls hashCode on it, uses that number to pick one bucketbucket: One slot of a hash table's array. A HashMap picks a key's bucket from its hash code, keeps the keys that land in the same bucket together, and searches them with equals. More in “String hashing, interning and locale traps”, and compares the key only with the entries in that bucket. Each entry keeps the hash code it was stored with, and the map calls equals only on an entry whose stored hash code is the same:

The diagram shows where the lookup goes. Step through the same call as it happens, one message at a time, and then the same call for EqualsOnlyPoint:

The set skipped Point(3, 20) without calling equals, because its stored hash code was another number, and it called equals once, on the argument, as the HashMap documentation describes get. For EqualsOnlyPoint it never got that far. That design is why the documentation of Object.hashCode lists three rules:

1. During one run of a program, calling hashCode on the same object must give the same number every time, as long as nothing that equals looks at has changed. The number may differ from one run to the next.
2. If two objects are equal according to equals, their hash codes must be the same.
3. Two unequal objects may share a hash code, a collisionhash collision: Two different keys with the same hash code, such as Aa and BB, which both hash to 2112. A hash table keeps both and tells them apart with equals; many collisions in one place make its lookups slow. More in “String hashing, interning and locale traps”. The contract allows it, but every shared hash code makes the table slower, as a later section measures.

EqualsOnlyPoint breaks rule 2. Its two equal points have the identity hash codes of two different objects, so the lookup goes to the wrong bucket and never meets the equal point. The documentation of Object.equals says it directly: whenever you override equals, you generally have to override hashCode too.

Point.hashCode returns Objects.hash(x, y), which hashes its arguments as if they were the elements of a list: start from 1, then for each value multiply by 31 and add the value’s own hash code. For (3, 4) that is 31 × (31 × 1 + 3) + 4 = 1058, the number in the diagram. Two cautions come with it. Objects.hash with a single argument does not return that argument’s hash code (the Javadoc warns about exactly this), so for one field write Objects.hashCode(field) instead. And it creates an array and boxes primitive values on every call, which can matter in code that hashes millions of keys; a hand-written 31 * x + y avoids both.

equals takes an Object, and @Override proves it

Point.equals is one line: return other instanceof Point p && x == p.x && y == p.y;. Each part has a job.

The parameter type is Object, because that is the method HashSet, HashMap, List.contains and every other library method call. A method equals(Point other) is a new, overloadedoverloading: Declaring several methods with the same name and different parameter lists in one class. The compiler picks one of them for each call from the types of its arguments: an exact or widened match first, then boxing, then varargs. More in “Methods, parameters, return and overloading” method that those libraries never use. The @Override annotation turns that mistake into a compile error, which is the reason to write it every time:

import java.util.Objects;

final class Point {
    private final int x;
    private final int y;

    Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    // Takes a Point, not an Object: this overloads equals instead of overriding it.
    @Override
    public boolean equals(Point other) {
        return other != null && x == other.x && y == other.y;
    }

    @Override
    public int hashCode() {
        return Objects.hash(x, y);
    }
}

void main() {
    Set<Point> points = new HashSet<>();
    points.add(new Point(3, 4));
    IO.println(points.contains(new Point(3, 4)));
}

Point.java:13: error: method does not override or implement a method from a supertype
    @Override
    ^
1 error
error: compilation failed

Without the annotation the same class compiles, and a HashSet of these points behaves like PlainPoint above.

other instanceof Point p tests the type and, when it matches, names the same object p with the type Point, a type patterntype pattern: A pattern such as Point p in other instanceof Point p: the test is true when other is a Point that is not null, and then p names the same object with the type Point, so no cast is needed. Part of Java since JDK 16. (JEP 394, part of Java since JDK 16). The test is false when other is null, so x.equals(null) returns false without a separate check, as the contract requires. It is also false for any object that is not a Point, so comparing a point with a string is simply false.

Then compare the fields that make up the value, and only those:

The Double documentation explains why its equals and compare treat every NaN as equal and the two zeros as different: it keeps equals reflexive, so an object holding NaN still equals itself.

The documentation of Object.equals asks for five properties, which make it an equivalence relation. It must be reflexive (x.equals(x) is true), symmetric (x.equals(y) and y.equals(x) agree), transitive (if x equals y and y equals z, x equals z), consistent (the answer only changes if the compared fields change) and x.equals(null) must be false. A final class that compares the same fields on both sides keeps all five with little effort. Symmetry and transitivity are the ones that break once a subclass joins in.

A subclass that adds a field breaks symmetry

A shop wrote Amount when it sold in one currency only: a sum of money in the smallest unit of that currency, so 5,000 for 50.00, compared by that number alone. The class is not final. When the shop started to sell in other currencies, someone extended it: CurrencyAmount adds a currency code, and its equals accepts only other CurrencyAmount objects and compares the code too:

/** An amount of money in the smallest unit of its currency (paise, cents). Not final, so a subclass can add a field. */
class Amount {
    final long units;

    Amount(long units) {
        this.units = units;
    }

    @Override
    public boolean equals(Object other) {
        return other instanceof Amount a && units == a.units;
    }

    @Override
    public int hashCode() {
        return Long.hashCode(units);
    }
}

import java.util.Objects;

/** Adds a currency code and compares it, so it accepts only other CurrencyAmounts. */
class CurrencyAmount extends Amount {
    final String currency;

    CurrencyAmount(long units, String currency) {
        super(units);
        this.currency = Objects.requireNonNull(currency, "currency");
    }

    @Override
    public boolean equals(Object other) {
        return other instanceof CurrencyAmount c && super.equals(c) && currency.equals(c.currency);
    }

    @Override
    public int hashCode() {
        return Objects.hash(units, currency);
    }
}

// The same 5,000 units with and without a currency, compared both ways round.
void main() {
    Amount plain = new Amount(5_000);
    Amount usd = new CurrencyAmount(5_000, "USD");
    IO.println("plain.equals(usd) = " + plain.equals(usd));
    IO.println("usd.equals(plain) = " + usd.equals(plain));
    IO.println("same hash code?     " + (plain.hashCode() == usd.hashCode()));

    // Each collection calls equals on a different side, so they disagree.
    Set<Amount> setOfPlain = new HashSet<>(List.of(plain));
    List<Amount> listOfUsd = new ArrayList<>(List.of(usd));
    IO.println("HashSet [plain] contains usd:   " + setOfPlain.contains(usd));
    IO.println("ArrayList [usd] contains plain: " + listOfUsd.contains(plain));
}

plain.equals(usd) = true
usd.equals(plain) = false
same hash code?     false
HashSet [plain] contains usd:   false
ArrayList [usd] contains plain: true

The plain amount says it equals the 5,000 US cents, because a CurrencyAmount is an instance of Amount and the units match. The dollar amount says the opposite. Collections inherit the disagreement: a HashSet holding plain says it does not contain usd, while an ArrayList holding usd says it contains plain, because ArrayList.contains calls equals on its argument. Which answer you get depends on which object happens to be on the left. The third line shows a second break: plain.equals(usd) is true while the two hash codes differ, which is rule 2 of the hash code contract broken, so the HashSet never even asks equals.

Letting CurrencyAmount accept plain amounts as well would only move the problem. Then $50.00 equals the plain 5,000, which equals €50.00, while the dollars and the euros differ: transitivity is gone, and the shop would call two different prices equal. As long as equals tests with instanceof, a subclass that adds a field to a value class has to give up one of the two properties. There are three ways out:

A final value class leaves nobody a way to subclass it, and records, three lessons on, are always final. Comparing classes exactly with getClass() == other.getClass() makes an Amount and a CurrencyAmount unequal either way round, at the price of a subclass that adds no state never equalling its parent. A CurrencyAmount that holds an Amount and a currency code, instead of extending Amount, has its own equals and no relationship to break; the module on inheritance comes back to that choice.

A constant hash code keeps answers right and makes lookups slow

return 42; is a legal hashCode: equal objects get equal hash codes, so the contract holds and every answer is right. This program counts how many times HashMap calls equals while it looks up every key once, for keys with a spread-out hash code, keys that all return 42, and keys that return 42 but also implement Comparable:

// Counts the equals calls HashMap makes while it looks up every key once, for three hashCode methods.
static long equalsCalls = 0;

/** A spread-out hash code: every id gets its own. */
static final class SpreadKey {
    final int id;
    SpreadKey(int id) { this.id = id; }
    @Override public boolean equals(Object o) { equalsCalls++; return o instanceof SpreadKey k && k.id == id; }
    @Override public int hashCode() { return Integer.hashCode(id); }
}

/** Legal but useless: every key gets the same hash code. */
static final class ConstantKey {
    final int id;
    ConstantKey(int id) { this.id = id; }
    @Override public boolean equals(Object o) { equalsCalls++; return o instanceof ConstantKey k && k.id == id; }
    @Override public int hashCode() { return 42; }
}

/** The same constant hash code, but the keys can be put in order. */
static final class SortableConstantKey implements Comparable<SortableConstantKey> {
    final int id;
    SortableConstantKey(int id) { this.id = id; }
    @Override public boolean equals(Object o) { equalsCalls++; return o instanceof SortableConstantKey k && k.id == id; }
    @Override public int hashCode() { return 42; }
    @Override public int compareTo(SortableConstantKey other) { return Integer.compare(id, other.id); }
}

long lookups(int n, IntFunction<Object> newKey) {
    Map<Object, Integer> map = new HashMap<>();
    for (int i = 0; i < n; i++) map.put(newKey.apply(i), i);
    equalsCalls = 0;
    for (int i = 0; i < n; i++) {
        if (map.get(newKey.apply(i)) == null) throw new AssertionError("lost key " + i);   // a new, equal key
    }
    return equalsCalls;
}

void main() {
    IO.println("keys    spread hash  constant 42  constant 42 + Comparable");
    for (int n : new int[] {1_000, 10_000}) {
        IO.println("%-7d %-12d %-12d %d".formatted(n,
                lookups(n, SpreadKey::new), lookups(n, ConstantKey::new), lookups(n, SortableConstantKey::new)));
    }
}

keys    spread hash  constant 42  constant 42 + Comparable
1000    1000         501499       10405
10000   10000        50014999     138852

With a spread-out hash code, each lookup finds its key at the first entry it compares: 1,000 lookups, 1,000 calls. With a constant hash code every key lands in the same bucket. Since JDK 8 a bucket that grows past a small size turns from a list into a balanced tree (JEP 180), but a tree needs an order, and keys with equal hash codes give it none. So each lookup searches the bucket until it meets its key: 501,499 calls for 1,000 keys, about n² ÷ 2. Ten times the keys means a hundred times the work, 50,014,999 calls for 10,000 lookups.

The third column is the escape hatch the HashMap documentation mentions: when keys are Comparable, the map may use their order to break ties. The tree is then searched like a sorted tree, about log₂ n comparisons per lookup, and 10,000 lookups cost 138,852 calls instead of fifty million. That rescues a hash code that collides by accident, but it is still about fourteen times the work of a spread-out hash, so the fix for return 42; is a real hash code. Counting calls rather than timing them gives the same numbers on every computer, which is why the program does it.

A key that changes after it goes in is lost

A hash table remembers each entry under the hash code the key had when it went in. If a field that hashCode uses changes afterwards, the entry sits in the bucket for the old number while the key now produces a new one. This Seat can move to another coach:

import java.util.Objects;

/** A seat whose coach can be changed after it is created: the mistake this example shows. */
final class Seat {
    private String coach;
    private final int number;

    Seat(String coach, int number) {
        this.coach = coach;
        this.number = number;
    }

    void moveTo(String newCoach) {
        coach = newCoach;
    }

    @Override
    public boolean equals(Object other) {
        return other instanceof Seat s && number == s.number && coach.equals(s.coach);
    }

    @Override
    public int hashCode() {
        return Objects.hash(coach, number);
    }

    @Override
    public String toString() {
        return coach + "-" + number;
    }
}

void main() {
    Map<Seat, String> bookings = new HashMap<>();
    Seat seat = new Seat("S4", 23);
    bookings.put(seat, "Asha");
    IO.println("booked: " + bookings + ", filed under hash code " + seat.hashCode());

    seat.moveTo("S5");                  // changes a field that hashCode uses, while seat is a key
    IO.println("map now prints:       " + bookings + ", key's hash code now " + seat.hashCode());
    IO.println("get(seat):            " + bookings.get(seat));
    IO.println("get(new Seat S5-23):  " + bookings.get(new Seat("S5", 23)));
    IO.println("get(new Seat S4-23):  " + bookings.get(new Seat("S4", 23)));
    IO.println("remove(seat):         " + bookings.remove(seat) + ", size still " + bookings.size());

    bookings.keySet().removeIf(key -> key == seat);   // only a full scan by identity finds it
    IO.println("after removeIf:       size " + bookings.size());
}

booked: {S4-23=Asha}, filed under hash code 82359
map now prints:       {S5-23=Asha}, key's hash code now 82390
get(seat):            null
get(new Seat S5-23):  null
get(new Seat S4-23):  null
remove(seat):         null, size still 1
after removeIf:       size 0

The map was given the hash code 82359, the number of S4-23, and after the move the same key says 82390. Step through where each lookup goes:

Printing the map shows the booking under S5-23, yet every lookup fails. get(seat) and a new S5-23 compute the new hash code and search the wrong bucket. A new S4-23 finds the right bucket and a matching stored hash code, but equals now compares it with a key that says S5. remove fails for the same reasons, and only a scan of every key, comparing by identity, gets rid of the entry. The documentation of Map warns that a map’s behaviour is not specified at all when a key changes in a way that affects equals; Set says the same for its elements.

The rule that follows: the fields that equals and hashCode read must not change while the object is a key or a set element. The reliable way to keep that rule is to make those fields final, which is where the next lesson, on immutability, starts.

toString is written for people, and leaves secrets out

Without an override, toString returns the class name, an @ and the hash code in hexadecimal. That text names the class and nothing else. The Object documentation recommends that every class override it with a concise text that a person can read easily, and requires the result never to be null.

import java.util.List;

/** A toString written for whoever reads the log: what the order is, without the card number. */
final class Order {
    private final String id;
    private final List<String> items;
    private final String cardNumber;

    Order(String id, List<String> items, String cardNumber) {
        this.id = id;
        this.items = List.copyOf(items);
        this.cardNumber = cardNumber;
    }

    @Override
    public String toString() {
        String last4 = cardNumber.substring(cardNumber.length() - 4);
        return "Order[id=" + id + ", items=" + items + ", card=**** " + last4 + "]";
    }
}

/** No toString: printing it shows Object's default. */
final class PlainOrder {
    private final String id;

    PlainOrder(String id) {
        this.id = id;
    }
}

void main() {
    IO.println(new PlainOrder("A-1009"));

    Order order = new Order("A-1009", List.of("kettle", "mug"), "1234567812345678");
    IO.println(order);                                  // println calls toString
    IO.println("placed " + order);                      // so does string concatenation
    IO.println(List.of(order));                         // and a list, which calls it for each element
}

PlainOrder@1f0f1111
Order[id=A-1009, items=[kettle, mug], card=**** 5678]
placed Order[id=A-1009, items=[kettle, mug], card=**** 5678]
[Order[id=A-1009, items=[kettle, mug], card=**** 5678]]

println, string concatenation and a collection’s own toString all call your toString, so the method ends up in logs, exception messages and debugger views whether you planned it or not. Three habits keep it useful:

• Name the class and the fields that identify the value, in one line. Order[id=A-1009, items=[kettle, mug]] tells you which order and what is in it.
• Leave out secrets. The OWASP Logging Cheat Sheet lists passwords, session identifiers, access tokens and payment card data among the things that should not reach logs as they are. Order prints only the last four digits of the card, so logging an order does not leak the card number.
• Treat it as text for people. The Object documentation says the output is not necessarily stable over time or across runs of the JVM, and a format meant for reading changes when someone improves it, so never parse it back into an object. When you need the identity form even though a class overrides toString, Objects.toIdentityString(object) (JDK 19 and later) returns it.

Records, three lessons on, generate all three methods from their fields, in the same shape as Order’s toString.

Practise: a ticket that works as a key

Ticket stands for one seat on one train: a train number, a coach and a seat. Two tickets with the same three values must count as the same ticket, in a HashSet and as a HashMap key. The starter class has the fields and a constructor, and the sample checks use it the way a booking system would:

import java.util.Objects;

/** One seat on one train. Two tickets for the same train, coach and seat should count as the same ticket. */
final class Ticket {
    private final int train;
    private final String coach;
    private final int seat;

    Ticket(int train, String coach, int seat) {
        this.train = train;
        this.coach = Objects.requireNonNull(coach, "coach");
        this.seat = seat;
    }

    // Your turn: override equals(Object), hashCode() and toString().
}

// Sample checks for Ticket. Edit Ticket.java, then run: java ticket/TicketChecks.java
int passed = 0;
int total = 0;

void check(String what, boolean ok) {
    total++;
    if (ok) passed++;
    IO.println((ok ? "pass  " : "FAIL  ") + what);
}

void main() {
    Ticket a = new Ticket(12951, "B2", 34);
    Ticket same = new Ticket(12951, "B2", 34);

    check("equal tickets are equal, both ways", a.equals(same) && same.equals(a));
    check("another seat is not equal", !a.equals(new Ticket(12951, "B2", 35)));
    check("another coach is not equal", !a.equals(new Ticket(12951, "B3", 34)));
    check("another train is not equal", !a.equals(new Ticket(12952, "B2", 34)));
    check("equals(null) is false", !a.equals(null));
    check("a String is never equal to a Ticket", !a.equals("12951 B2 34"));
    check("equal tickets have equal hash codes", a.hashCode() == same.hashCode());

    Set<Ticket> unique = new HashSet<>(List.of(a, same, new Ticket(12951, "B2", 35)));
    check("a HashSet keeps one of two equal tickets", unique.size() == 2);
    Map<Ticket, String> holders = new HashMap<>();
    holders.put(a, "Asha");
    check("a HashMap finds the holder by an equal ticket", "Asha".equals(holders.get(same)));
    check("toString is Ticket[train=12951, coach=B2, seat=34]", a.toString().equals("Ticket[train=12951, coach=B2, seat=34]"));

    IO.println(passed + " of " + total + " checks passed");
    if (passed < total) System.exit(1);
}

FAIL  equal tickets are equal, both ways
pass  another seat is not equal
pass  another coach is not equal
pass  another train is not equal
pass  equals(null) is false
pass  a String is never equal to a Ticket
FAIL  equal tickets have equal hash codes
FAIL  a HashSet keeps one of two equal tickets
FAIL  a HashMap finds the holder by an equal ticket
FAIL  toString is Ticket[train=12951, coach=B2, seat=34]
5 of 10 checks passed

Edit Ticket.java until java ticket/TicketChecks.java prints 10 of 10 checks passed:

1. Override equals(Object) with @Override. Use a type pattern and compare all three fields: the numbers with == and the coach with equals.
2. Override hashCode so that it reads the same three fields, for example with Objects.hash.
3. Override toString to return exactly Ticket[train=12951, coach=B2, seat=34] for that ticket.

Then break it on purpose: change the parameter of equals to Ticket, keep the body working (with a null check), and delete @Override. The checks that call equals directly still pass, because the compiler picks the overload, but the HashSet and HashMap checks fail, as they did for EqualsOnlyPoint.

Then test yourself on the seven ideas, from what Object compares to toString. The idea you have answered worst so far comes up first, and each choice explains itself as soon as you pick it:

Interview questions

Fresher · What is the contract between equals and hashCode in Java?

Equal objects must have equal hash codes: if a.equals(b) is true, a.hashCode() == b.hashCode() must be true too. The reverse is not required, so unequal objects may share a hash code, but every collision makes hash tables slower. A hash code must also stay the same during a run as long as the fields that equals compares do not change. The reason is how HashMap and HashSet work: they use the hash code to pick a bucket and call equals only inside it, so an object whose equal twin has another hash code is never found. That is why overriding equals alone is a bug, and why both methods should read exactly the same fields. A good answer adds that fields used by both should be final, because a key whose hash code changes after insertion is lost in the map.

Two longer questions of this module start from this lesson: a set of orders that keeps growing, and a cache whose key class returns 42 from hashCode.

Key takeaways

• Object treats every object as unique; a value class overrides equals so that equal values compare equal, and hashCode with it, because hash tables compare hash codes before they ever call equals.
• Override equals(Object) with @Override, a type pattern and the same fields as hashCode: an equals(Point) overload compiles silently, and no collection ever calls it.
• Compare integer fields with ==, floating-point ones with Double.compare, objects with Objects.equals and arrays with Arrays.equals; a non-final class whose subclass adds a field cannot keep equals symmetric.
• A constant hash code keeps every answer right and makes lookups slow: 1,000 lookups cost 501,499 equals calls instead of 1,000.
• A key whose hash code changes after it goes into a map or a set is lost, so the fields that equals and hashCode read should be final.
• Write toString for the person reading a log: the class and its identifying fields, never a password or a full card number, and never parse it back.