The previous lesson ended with a legitimate annoyance: Catalog.ByTitle is a complete class — declaration, @Override, body, name and a slot in the namespace — for a single line of logic used in exactly one place. When the code you want to write fits on one line and the ceremony wrapping it takes five, something is redundant.

Anonymous classes remove that ceremony. They let you declare an implementation and instantiate it in the same expression, at the exact point where it is needed and without giving it a name. For fifteen years they were Java's standard mechanism for passing behaviour to a method: every Comparator, every GUI listener, every Runnable was written that way. Today lambdas have taken over much of that ground, but anonymous classes are still the only option in several specific scenarios, and above all they still appear throughout all existing Java code: reading them fluently is not optional. Besides, understanding them thoroughly is the best possible preparation for lesson 04-05, because a lambda is nothing more than an anonymous class with everything dispensable stripped away.

1. What an anonymous class is
2. The syntax, dissected
3. What it can and cannot do
4. The instance initialisation block
5. Its own methods: they exist, but they are almost useless
6. Capturing effectively final variables
7. this inside an anonymous class
8. Classic use 1: a Comparator for the catalogue
9. Classic use 2: a callback
10. Classic use 3: extending a class on the spot
11. When it is still the right option and when to use a lambda
12. "Double brace initialization" and why to avoid it
13. Bytecode weight and readability
14. Final decision table
15. Common Mistakes and Tips
16. Exercises

An anonymous class is a class without a name that is declared and instantiated in a single expression. It can be:

• An implementation of an interface, or
• A subclass of a class (concrete or abstract).

Compare the two ways of obtaining a comparator by title:

The second form declares no named class, takes up no place in Catalog's namespace and puts the logic exactly where it is used. Whoever reads Arrays.sort(...) sees at once which criterion the sorting uses, without going off to find another file.

The expression new Comparator<Material>() { ... } does three things at once:

1. It declares a new class implementing Comparator<Material>.
2. It instantiates it.
3. It returns that instance as the value of the expression.

This is the part worth examining under a magnifying glass, because it has a peculiar structure:

Piece by piece:

That final semicolon is the number one source of errors with anonymous classes. The reason is that the whole construct is an expression inside a statement, not a class declaration. Think of it this way: if you write int x = 5;, the ; is obvious. The same thing happens here; what throws you off is that there is a closing brace in the middle, and the eye reads it as the end of a class.

When the anonymous class goes in as a method argument, the closing parenthesis appears after the brace, something that looks jarring at first:

That }); is the visual signature of an anonymous class in Java code. Learn to recognise it.

The central limitation is having no constructor. And the reason is simple: a constructor carries the name of its class, and this class has no name. There is no way to write it.

And what if you extend a class that does have a constructor? Then you can pass it arguments in the new parentheses, which are forwarded to the superclass constructor:

Here ("Nuria Vidal", "EMP-003") is not the anonymous class's constructor: it is the invocation of Employee's constructor. The anonymous class gets an implicit constructor that merely forwards them.

If there is no constructor, how do you initialise a field with logic? With an instance initialisation block: a loose { ... } block in the class body, which runs when the object is constructed, right after the superclass constructor.

This mechanism is not exclusive to anonymous classes — any class can have one — but here it is the only way to run initialisation code. The full order, extending what you saw in 03-04, is:

In practice, if your anonymous class needs a complex initialisation block, take it as a signal: it probably deserves to be a named class.

An anonymous class can declare methods that are not in the interface or the base class. They compile. But there is a catch:

The reason is the polymorphism rule from 03-06: the declared type decides what you can call. The variable's type is Comparator<Material>, and Comparator has no getComparisons(). And you cannot declare it with the actual type, because the actual type has no name.

There is a loophole, useful for understanding the mechanism even if you never use it: invoking the method on the expression itself, before the type is lost.

It works because the compiler knows the anonymous type as long as the expression lasts. As soon as you assign it to a variable, the type generalises and the method becomes unreachable.

Practical conclusion: an anonymous class's own methods are only useful inside it, as private helpers for the method that is part of the contract. If you need to expose new methods, you need a named class.

Exactly the same rule as for local classes applies (04-03): an anonymous class can read local variables and parameters of the surrounding method, provided they are final or effectively final.

If at any point in the method you wrote elapsedDays = 30;, the variable would stop being effectively final and the error would appear inside the anonymous class:

The reason is the one you studied in 04-03: the local variable lives on the stack and dies with the method; the anonymous object lives on the heap and can outlive it. Java copies the value inside the object, and allowing modification would produce two uncoordinated copies.

And an important note that avoids confusion: the restriction applies to the variable, not to the object. You can capture a reference and modify the object it points to:

Runnable is the interface for runnable tasks; its real use with threads is module 8.

This is the point that causes the most subtle errors in the module, and it deserves full attention.

Inside an anonymous class, this refers to the anonymous class itself, not to the class surrounding it.

The last two lines prove it beyond doubt: this is an object of the class LoanManager$1, the anonymous class the compiler generated (04-03, section 9).

To reach the outer instance you have to write OuterClass.this, the same syntax as with inner classes.

Why does it matter so much? Because the typical mistake is silent:

That access works because there is no lastCriterion in the anonymous class. But as soon as the anonymous class declares a field with the same name — or you call a record() method that exists in both — the resolution changes destination without warning and the program does something different from what you expected. The resolution rule, just as in 04-03: local variable → member of the anonymous class → member of the outer class.

Keep this table, because in 04-05 you are going to compare it with the behaviour of lambdas and you will see it is exactly the opposite:

The most frequent use. Here is the Catalog from 04-03 rewritten with anonymous classes, plus a third, composite criterion:

sortedByTypeAndTitle is a good example of an anonymous class that is still justified: it has several lines of logic with an intermediate condition. Sorting like this with a single compare is exactly what Comparator.comparing().thenComparing() will solve more elegantly in 04-06.

A callback is an object with behaviour that you pass to another one so that it invokes it when something happens. It is the mechanism that lets a service class notify without knowing whom.

And now the usage, with two different listeners defined at the exact point where what to do is decided:

Notice what has been achieved: LoanManager knows nothing about receipts or alerts. It only knows the ReturnListener interface and calls its method. It is the dependency inversion of 04-01 in action, and it is the basis of the Observer pattern you will formalise in 12-02.

Anonymous classes also serve to create a one-off variant of an existing class, typically in tests:

And with abstract classes, which cannot be instantiated (04-02) but can be extended anonymously:

This use — creating on the fly a minimal implementation of an abstract class to test the base logic — is very common in module 11 with JUnit. And note the detail: new Material(...) is forbidden, but new Material(...) { ... } is legal, because it does not instantiate Material but an anonymous subclass that is concrete.

Java 8 brought lambdas, which express the same thing in far less space:

But the lambda does not replace the anonymous class in every case. The rule is categorical:

A lambda can only implement an interface with a single abstract method (a functional interface, 04-06). For everything else, an anonymous class is still needed.

An example of an irreplaceable anonymous class, with its own state between calls:

The full syntax of the lambda, its shorthand forms and its rules are the content of lesson 04-05. Here it is enough to know that it exists and when it will not do.

There is a widely circulated trick that combines an anonymous class with an initialisation block to initialise objects "inline". It is called double brace initialization because of the two consecutive braces:

It reads like this: the first brace opens the anonymous class, the second opens an instance initialisation block. It looks elegant and compact. It is a recognised bad practice, for four concrete reasons:

1. It creates an extra class per use. Each {{ }} generates one more .class file. A method called a thousand times with this syntax in a loop generates one class, yes, but a thousand instances of an unnecessary subclass.
2. The object is no longer of the class you think. marta.getClass() returns App$1, not Employee. And since well-written equals methods compare with getClass() (03-09), marta.equals(otherEmployee) returns false even if they have the same identifier. It is a real bug and a hard one to find.
3. It retains the outer instance. It is a non-static inner class: it drags along the hidden this$0 reference with everything that entails (04-03), including the memory leak if the object is stored in a cache.
4. It breaks serialisation. An anonymous class does not serialise well (module 7).

The correct alternatives have been within your reach since module 3:

Two costs worth keeping in mind.

One class per anonymous class. The compiler generates Outer$1.class, Outer$2.class, Outer$3.class... numbering them in order of appearance. Consequences:

• More files in the .jar and more class-loading time at startup.
• Cryptic error traces: at com.nexussoftware.bibliotech.service.Catalog$2.compare(Catalog.java:41). The name says nothing; you have to go to line 41 to know which comparator is meant.
• Renumbering: if you add an anonymous class before another, all the following ones change number. In debugging this is disorienting.

Lambdas mitigate this, because they do not generate one class per lambda: they use the invokedynamic instruction and create the implementation at run time. It is one of their less well-known advantages and it is the reason lambdas do not make startup more expensive the way thousands of anonymous classes used to.

Readability. A three-line anonymous class improves reading, because it puts the logic where it is used. A thirty-line anonymous class wrecks the reading of the method containing it: the main flow is buried under a class declaration. The most useful informal rule:

If the anonymous class does not fit entirely on the screen together with the code around it, move it out to a named class.

This is the summary of the module so far. Keep it: it answers the question "which form of class do I use?" in almost any real situation.

Forgetting the final semicolon. }; closes a statement, not a class. It is the number one error, and the compiler's message (';' expected) points at the following line, which is disorienting.

Trying to write a constructor. It does not exist. Use an instance initialisation block, or pass the arguments to the superclass constructor in the new parentheses.

Calling one of the anonymous class's own methods from outside. It does not compile: the variable has the type of the interface or the superclass. If you need to expose new methods, you need a name.

Believing that this is the outer class. It is the most expensive conceptual mistake. Inside the anonymous class, this is the anonymous class. Use Outer.this. And get ready for this to be exactly the other way round with lambdas in 04-05.

Modifying a captured local variable. Forbidden: it must be effectively final. But you can modify the object a captured reference points to.

Using double brace initialization. It changes the object's actual class, breaks equals based on getClass(), retains the outer instance and generates extra classes.

Giant anonymous classes. A thirty-line anonymous class inside a method call is an unreadable method. Move it out.

Tip: always put @Override. Just as with inheritance (03-05), it instantly detects a badly written signature. Without it, a mistyped compare(Material a, Object b) becomes a new method and the compiler complains much later and much worse.

Tip: name the variable if you are going to reuse the anonymous class. If the same comparator is used in three methods, assign it to a field private static final Comparator<Material> BY_TITLE = new Comparator<>() { ... };. A single instance is created and the name documents the criterion.

Tip: the diamond <> works from Java 9 onwards. new Comparator<>() { ... } is valid and saves repeating the type. Before Java 9 you had to write new Comparator<Material>() { ... }.

Write a method static void showSorted(Material[] materials, String criterion, int days) that sorts a copy of the array with Arrays.sort using a different anonymous class depending on the criterion received: "title" (alphabetical ascending), "term" (shortest term first) and "fine" (highest fine first, for the given days). Use an arrow switch (02-03). Test all three with the BiblioTech catalogue.

Extend the LoanManager from section 9. Write an anonymous ReturnListener class that accumulates the number of returns and the total of fines in its own fields, and prints a summary every three returns. Explain why this anonymous class could not be a lambda.

Write a class Auditor with a field private String source = "Auditor" and a method audit() that creates an anonymous Runnable class with its own field source = "Task". Inside run(), print: the anonymous class's field, the outer class's field, the class name of this and the class name of Auditor.this. Predict the output before running it.

Solution 1

Two technical notes. First: Integer.compare(a, b) and Double.compare(a, b) instead of manual subtractions; subtracting integers can overflow and subtracting doubles forces you to convert the result to int, losing precision. Second: the order between the two 15-day books stays as they were in the array, because Arrays.sort on objects is stable. That detail will matter a lot in 05-09.

And an observation anticipating the next lesson: all four bodies have exactly one line of useful logic, each wrapped in five lines of ceremony. In 04-05 this whole method will come down to four lines.

Solution 2

Why it cannot be a lambda: a lambda has no fields. Its body can only use its parameters, the members of the enclosing class and captured local variables, and the latter must be effectively final, that is, they cannot be incremented. Here returnCount and totalFines change on every invocation and their value must persist between calls: that requires state in the object, and state in the object requires a class. Besides, this anonymous class uses an initialisation block, something that does not exist in a lambda either. It is the textbook case where the anonymous class is still the right tool in Java 17.

Solution 3

Line-by-line analysis:

1. source without a prefix returns "Task". Resolution goes from the inside out: there is no local variable with that name, so the anonymous class's field wins and Auditor's is shadowed. This is exactly the mechanism by which an innocent change — adding a field to the anonymous class — silently redirects accesses that used to go to the outer class.
2. this.source is the same as line 1, and here it is explicit: this is the anonymous class.
3. Auditor.this.source is the only way to reach the enclosing class's field.
4. this.getClass() returns Auditor$1, the class the compiler generated (04-03, section 9). The 1 indicates it is the first anonymous class in Auditor; if you add another before it, this one becomes Auditor$2.
5. Auditor.this.getClass() returns Auditor, confirming they are two different objects.

Repeat this same exercise after finishing 04-05, replacing the anonymous class with a lambda: all five lines change their result, because in a lambda this is the outer class. That difference is the number one source of errors when migrating old code from anonymous classes to lambdas.

You now know how to declare and instantiate an implementation in a single expression and without giving it a name. You have mastered the dissected syntax — the type being implemented or extended, the parentheses that go to the superclass constructor, the body in braces and that final semicolon which closes a statement, not a class — and you recognise }); as the visual signature of an anonymous class in any Java code you open.

You know its limits and the reason for each one: it cannot have a constructor because a constructor carries the name of its class and this one has none, and that is why the instance initialisation block exists; it can declare its own methods, but they are unreachable from outside because the variable has the interface's type and the actual type cannot be named; and it captures effectively final variables, with the same rule and the same reason as local classes. And you are very aware of the trap that costs the most: inside an anonymous class, this is the anonymous class, not the enclosing one; to reach the latter you have to write Outer.this.

You have seen the three uses that made it Java's workhorse for fifteen years: the Comparator that sorts the BiblioTech catalogue by title, by term or by fine; the callback that lets LoanManager notify without knowing whom, with two different listeners defined where the decision about what to do is made; and the one-off extension of a class, including an abstract one, which makes new Material(...) { ... } legal where new Material(...) is forbidden. You know why double brace initialization is bad practice — it changes the object's actual class and breaks equals, retains the outer instance and generates extra classes — and what each anonymous class costs in the bytecode: a numbered .class, cryptic traces and renumbering when you reorder.

And above all you take away the decision table: a top-level class when the type has substance, a static nested one for helpers, a local one for types belonging to a single algorithm, an anonymous one when you need state, several abstract methods or to extend a class, and a lambda when none of that is needed.

Because that last row is what comes next. Look back over the comparators you have written in this lesson: each has one line of logic wrapped in five of ceremony. The compiler already knows the interface's name, because the parameter of Arrays.sort says so. It knows the method's name too, because Comparator has only one. It knows the types of a and b too. All of that is redundant. In lesson 04-05, Lambda Expressions, you will strip the ceremony away piece by piece until only what carries information is left, you will learn the full syntax with all its shorthand forms, you will understand what a lambda really is — not a function pointer, but the implementation of a functional interface — you will see why this behaves the opposite way to here, and you will write your own BiblioTech functional interfaces to change a class's behaviour without touching its code.