Your classes already model the domain, protect their invariants and expose a minimal API. And yet, if you print a book you get this: com.nexussoftware.bibliotech.domain.Book@1b6d3586. And if you compare two copies of "Effective Java" with the same ISBN, Java tells you they are not equal. Both behaviours come from the same place: the Object class, root of Java's whole hierarchy, which provides default implementations of a set of universal methods. Those implementations work, but they are deliberately conservative: toString does not know what is important about your class and equals does not know what "equal" means in your domain. Only you can say. This lesson teaches you to do it properly, with the complete contract of each method, because a badly written equals and hashCode produce bugs that do not show up until your objects enter a collection, and by then the failure looks like black magic. And by the end, you will close the module by keeping the promise you left at the end of module 2.

1. Object, the root of everything
2. A tour of Object's methods
3. toString: what that @1b6d3586 is
4. Overriding toString correctly
5. equals: reference equality versus logical equality
6. The equals contract
7. Implementing equals step by step
8. The classic mistake: equals(Book) instead of equals(Object)
9. hashCode: the contract and why it always goes with equals
10. Implementing hashCode with Objects.hash
11. What breaks if you do not override hashCode
12. getClass() versus instanceof in equals
13. Objects.equals and Objects.requireNonNull
14. Closing the module: BiblioTech's final refactoring
15. Common Mistakes and Tips
16. Exercises

As you saw in 03-05, every Java class inherits from java.lang.Object, directly or indirectly. If you do not write extends, the compiler puts it in for you.

This has two practical consequences you have already benefited from without knowing it:

• Every object has Object's methods. You can call toString() on anything.
• Object serves as a universal common type. An Object parameter accepts any object, and that is why System.out.println(Object) works with whatever you throw at it. It is the polymorphism of 03-06 taken to the limit.

Two clarifications about the problematic rows:

clone() is discouraged. Its design forces you to implement the marker interface Cloneable, produces shallow copies by default and has a confusing interaction with final and inheritance. The alternative is the one you already know: a copy constructor.

finalize() must never be used. It has been deprecated since Java 9 and removed from practical use: there is no guarantee that it will run, nor when, nor even that it will run at all. To release resources there is try-with-resources, studied in lesson 06-06.

When you concatenate or print an object, Java calls its toString():

The default implementation in Object is, literally:

Broken down:

And here it is worth clearing up a very widespread misunderstanding: that number is not the memory address. It is the value returned by hashCode(), which in the default implementation derives from the object's identity, but which the JVM can compute in several ways and which does not change even if the garbage collector moves the object elsewhere. It is an identifier, not a position.

As an identifier it works; as information, it is useless. That is why toString is almost always overridden.

A good toString is short, informative and free of side effects. It must contain the data that identifies the object to a human.

Practical rules:

A useful toString for Loan, delegating to what it already knows:

That change, on its own, radically improves debugging: the IDE's variables window and any System.out.println start showing readable information instead of @1b6d3586.

Let us pick up == from module 1, now with your own objects. There are two notions of equality:

With Object's default implementation, both are identical, because Object.equals is exactly this:

Hence the surprising behaviour:

Is that correct? It depends on what "equal" means in BiblioTech. And that is a business decision, not a technical one:

• If Book represents a bibliographic work, two objects with the same ISBN are the same book. → equals must be overridden.
• If Book represents a physical copy, two copies of the same work are different things even if they share an ISBN. → identity equality is correct.

In BiblioTech we adopt the first interpretation: two books are equal if they have the same ISBN. It is the definition the publishing industry itself uses, and it fits our domain vocabulary.

Remember too the module 1 lesson with String: "Effective Java" == otherString can give false even though the text is identical, and that is why you always compared with equals. Now you know exactly why: String does override equals to compare the content.

equals is not just any method: it has a contract that the whole Java standard library assumes you honour. If you break it, module 5's collections will behave unpredictably and it will not be their fault.

For non-null references x, y, z:

The most frequent violation in real code is symmetry, and it usually appears like this:

String.equals will never consider a Book equal, so the relation is not symmetric and any collection depending on it will fail in an apparently random way.

Tip derived from the contract: compare only with objects of your own type.

The canonical structure has five steps, and it is best to always write it the same way:

With Java 16's instanceof with a pattern (lesson 03-06), steps 2 and 3 merge into one:

Check:

Look at the a.equals(b) case: the titles and years differ, but the ISBN matches, so they are the same book. That is exactly what we decided in section 5: equality is defined by the domain, not by all the fields matching.

On which fields to use, three criteria:

1. Only fields significant to identity. A derived field or one of transient state (like available) must not go in.
2. Preferably final fields. If a field used in equals changes, the object changes identity, with the consequences from section 11.
3. Careful with the types: for float and double, use Float.compare / Double.compare instead of ==, because NaN != NaN would break reflexivity, and 0.0 and -0.0 are == but differ at the bit level.

This is the mistake you have to see once so as never to repeat it. Look at the signature:

It compiles without a single complaint. And it works... sometimes:

The same pair of objects, two opposite results. Why?

Because equals(Book) and equals(Object) have different signatures: they are an overload, not an override (table from 03-05). And overloading is resolved at compile time, from the declared type (03-06). With a and b declared as Book, the compiler picks your method; with oa and ob declared as Object, it picks Object's, which compares references.

And the worst part is that all of module 5's collections call equals(Object), because internally they work with generic references. So your method would never be used where it is most needed, and the bug would show up as "the HashSet has duplicate books" with no clue about the cause.

The defence is the annotation you already know:

One second writing @Override versus an afternoon debugging. This is probably the most compelling of all the reasons we have given for always adding it.

hashCode() returns an integer that summarises the object's content. Its use is in hash-table-based structures —HashMap and HashSet, module 5—, which use it to locate objects quickly without comparing them one by one.

Its contract has three clauses:

Clause 2 is the one that imposes the golden rule:

Whenever you override equals, override hashCode. No exceptions.

The logic is inescapable: if two objects are "equal" but produce different hash codes, a hash table will put them in different buckets and will never compare them with each other, so it will never discover that they are equal.

Good news: clause 3 means a hashCode does not have to be unique. Collisions can happen; the structure resolves them by comparing with equals inside the bucket. A hashCode that always returned 0 would be correct (it honours the contract) but useless, because it would degrade the HashMap into a linear search.

The modern, recommended way is one line, using the utility class java.util.Objects:

Essential rule: hashCode must use exactly the same fields as equals. If equals compares the ISBN, hashCode is computed from the ISBN. If you add a field to one, add it to the other. It is the number one cause of inconsistencies.

With several fields:

Objects.hash(...) is a varargs method (03-03) that combines its arguments' hash codes with a standard algorithm. Internally it does the same as the classic formula, which is worth knowing because you will see it in old code and in interviews:

31 is used because it is an odd prime and because 31 * x is optimised into (x << 5) - x. You do not need to write it by hand: Objects.hash is more readable and good enough.

A performance caution: Objects.hash creates an internal array for the varargs, so in classes with millions of instances in critical loops it can be noticeable. For everything else —including BiblioTech—, it is the right option.

This section justifies everything above. Suppose you override equals in Book but forget hashCode:

They are "equal" and have different hash codes: clause 2 is broken. The consequences, which you will suffer in module 5:

A HashSet that admits duplicates. A HashMap where you store with one key and cannot retrieve with an identical one. And no error, no exception, no clue: simply, incorrect results.

There is the key to the diagram: if the hashCode does not match, equals is never even called. That is why the bug is so baffling: your equals is perfect and the result is still wrong.

Final rule, in one sentence: equals and hashCode are written together, modified together and reviewed together.

There is a design decision in step 2 of equals, and it is worth knowing because it has real implications with inheritance.

The instanceof variant (the one we have used):

The getClass() variant:

The difference appears with subclasses. Imagine a SignedBook extends Book:

The classic instanceof problem: if SignedBook overrides equals adding the signer to the comparison, then book.equals(signedBook) would give true (it only looks at the ISBN) while signedBook.equals(book) would give false (it also looks at the signer). Asymmetry, and a broken contract.

Decision for BiblioTech. Since Book may have subclasses and we want bulletproof symmetry, the definitive implementation will use getClass(). And the cleanest alternative is still the one from 03-07: declare the class final when it is not designed to be extended, at which point the dilemma disappears.

Note on record. A record (lesson 04-07) automatically generates equals, hashCode and toString from all of its components, with the contract correctly implemented. It is the best reason to use them for immutable data objects. But note the nuance: the generated equals uses all the components, whereas ours uses only the ISBN. If your notion of equality is not "all the fields match", a record does not serve you as is.

The java.util.Objects class provides two utilities you will see constantly.

Objects.equals(a, b) compares two references handling null correctly, without you having to write the guard:

Its implementation is exactly (a == b) || (a != null && a.equals(b)). Always use it inside equals when a field can be null.

Objects.requireNonNull(object, message) checks that a reference is not null and fails immediately if it is. Its value lies in failing early and with a clear message, in the constructor, instead of letting a null travel through the system and blow up three layers further on:

If somebody passes null, the program stops right there with:

Compare it with the "Unknown material" placeholder we had been using: that one masked the error and let the system carry on with false data. requireNonNull is the first correct way of rejecting an invalid argument that you see in the course, and it is a foretaste of module 6, where you will learn to throw exceptions deliberately. From now on, in the domain classes, it is preferable to console warnings.

The time has come to keep the promise that closed module 2. Remember the problem:

The three flaws we pointed out then: nothing guarantees the three are updated together; the compiler cannot help; and if tomorrow you want to add the fine or the reference, you have to add a fourth variable and another line to remember.

With what you have learned in the module, the three variables become one:

A single assignment. It is impossible to leave the state half-done, because there are no parts to update separately: either the whole object changes, or nothing changes. And displaying it is one line, thanks to toString:

Compare the two versions:

The domain classes, with their three Object methods implemented:

And a main that no longer calculates anything:

Output:

What is still missing, and you already know where it is solved:

• Overriding equals and forgetting hashCode. The most expensive mistake in this lesson: nothing fails until the objects enter a HashSet or a HashMap, and then it fails silently.
• Writing equals(MyClass) instead of equals(Object). Overloading instead of overriding. @Override detects it instantly.
• Using different fields in equals and hashCode. It breaks clause 2 of the contract. Always write them at the same time and with the same fields.
• Using mutable fields in equals/hashCode. If the field changes while the object is in a collection, the object becomes unfindable inside it. Use final fields.
• Comparing double with == inside equals. NaN != NaN breaks reflexivity. Use Double.compare.
• Formatting data with toString in order to process it. If other code parses your toString, it becomes an API you will not be able to change. There are specific methods for that.
• A toString that recurses between objects referencing each other. StackOverflowError. Print the other object's identifier, not the whole object.
• Tip: let the IDE generate them. IntelliJ (Alt+Insert → equals() and hashCode()) and Eclipse (Alt+Shift+S) generate all three implementations with the correct contract. Write them by hand once to understand them, and use the generator afterwards.
• Tip: if the class is an immutable data holder, consider a record (04-07): it gives you the three methods for free and with the contract properly implemented.
• Tip: test the contract. Four asserts or four printlns checking reflexivity, symmetry, transitivity and null cost a minute and catch 90 % of the errors. In module 11 you will do it with JUnit.

Implement toString, equals and hashCode in Material and decide what the subclasses should do:

1. In Material, equality is defined by reference (a book's ISBN, a DVD's code...).
2. Use getClass() to guarantee symmetry, and check with console output that a Book and a Dvd with the same reference are not equal.
3. Override toString in Material including type, title, reference and availability, and check it with the four subclasses.
4. Argue in writing whether Book, Magazine and Dvd need to override equals and hashCode, or whether inheriting them is enough.

Write a test class that demonstrates the mistake from section 8 in a single run:

1. A class BadBook with public boolean equals(BadBook other) (without @Override).
2. Two objects with the same ISBN.
3. Compare them with references declared as BadBook and with references declared as Object, printing both results.
4. Add @Override and copy the compiler's exact message.
5. Fix the signature and check that both results now agree.

Write a method static boolean checkContract(Object x, Object y, Object z) that checks the five properties of the equals contract on three objects and prints a report with the result of each, plus coherence with hashCode. Test it with:

1. Three correct Books: two with the same ISBN and one different.
2. A class BookWithoutHashCode that overrides equals but not hashCode, to see which check fails.

Solution 1

Checking symmetry between different types:

Output:

Notice an elegant detail of Material's toString: it uses getType(), which is polymorphic, so each subclass identifies itself without needing to override toString. It is lesson 03-06 applied here.

4. Should the subclasses override equals and hashCode? No, and they should not. Three reasons:

• The reference already identifies any material in the catalog uniquely: there are no two books with the same ISBN nor two DVDs with the same code. Adding author or durationMinutes to the comparison would distinguish nothing new.
• Overriding equals in a subclass adding fields is precisely the source of the asymmetries in section 12. Since Material.equals uses getClass(), a Book and a Dvd are never equal anyway; the problem is solved in the base class.
• If they needed to compare more fields, hashCode would have to be updated at the same time in each subclass, multiplying the opportunities for error.

The rule that follows: define equality only once, at the highest level of the hierarchy where it makes sense, and use a stable identifying field rather than the sum of all the fields.

Solution 2

Output:

The traces make it crystal clear: in the incorrect version, the call through Object does not even enter your method —the message does not appear—, because the compiler resolved the call to Object.equals. In the correct one, your method runs in both cases.

4. Compiler message when adding @Override:

Five words that would have saved you the whole bug. In a HashSet (module 5), the incorrect version would produce duplicates with no sign of an error at all.

Solution 3

Output:

The revealing thing about case 2: the equals is impeccable —it honours all five properties— and the class is still broken. That is exactly why the failure is so hard to find in a real project: every equality test passes, and the system fails much later, inside a HashMap, without throwing any exception.

Two technical notes on the checker. First, the transitivity check only makes sense when the antecedent holds; if x and y are not equal, the implication is vacuously true and there is nothing to verify. Second, this checker is a foretaste of what you will do in module 11 with JUnit, where these checks are written as automated tests that run on every build instead of printing to the console.

You have come full circle. You know that Object is the root of the whole hierarchy and you know its methods, including the ones you must not touch (getClass), the discouraged ones (clone), the deprecated ones (finalize) and those that wait until module 8 (wait/notify). You understand what the cryptic Book@1b6d3586 is —the class name and the hashCode in hexadecimal, not a memory address— and you know how to replace it with a short, informative, side-effect-free toString that transforms debugging. You distinguish reference equality from logical equality, and you know that deciding which applies is a domain decision: in BiblioTech, two books are the same book if they share an ISBN. You master the complete equals contract —reflexive, symmetric, transitive, consistent and false against null— and its canonical five-step implementation, with the modern instanceof-with-pattern variant. You have seen in action the classic mistake of writing equals(Book) instead of equals(Object), and why @Override is the difference between a second and a wasted afternoon. You know the hashCode contract, the unbreakable rule of always overriding it alongside equals and with the same fields, Objects.hash for writing it in one line, and exactly what breaks if you forget: a HashSet with duplicates and an equals that nobody ever reaches. And you add Objects.equals and Objects.requireNonNull to your vocabulary, the first correct way of rejecting an invalid argument that you see in the course.

With this you close module 3, and BiblioTech is a different program. Where there were twenty loose variables in a two-hundred-line main, there are now eight classes spread over three packages: a Material hierarchy with three formats that apply their own rules through polymorphism, an Employee that enforces its limit, a Loan that computes its due day at birth and registers complete returns in a single call, a presentation layer separated from the domain, and objects that print and compare properly. The fields are private, the invariants are guaranteed, the public API is pruned and adding a new format costs one class and zero modifications. And those three awkward variables —highestDelay, highestDelayEmployee and highestDelayBook— are today a single coherent Loan object, exactly as promised at the end of module 2.

In module 4, Advanced OOP, you will take the leap from the basic mechanisms to the ones Java's professional libraries really use. You will turn Material into an abstract class that cannot be instantiated and that forces its subclasses to implement what is theirs; you will discover interfaces, with which a class can commit to several contracts at once without multiple inheritance; you will meet inner and anonymous classes, lambda expressions and method references that completely change the way modern Java is written; and you will finish with enums and records, which will replace those "MINOR" and "SEVERE" strings with safe types and will generate on their own the three methods you have just written by hand. BiblioTech is ready to grow.