Why couldn't the diamond operator originally be used with anonymous classes, and what changed in Java 9?

## Background: what an anonymous class is An **anonymous class** is a class with no name, declared and instantiated in one expression, that implicitly extends a class or implements an interface: ```java Comparator<String> c = new Comparator<String>() { public int compare(String a, String b) { return a.length() - b.length(); } }; ``` Under the hood the compiler generates a hidden subclass (e.g. `Outer$1`) and creates an instance of it. With generics, that synthetic subclass needs a concrete type argument — here `String`. ## Why the diamond was banned (Java 7-8) When you use the diamond, the compiler **infers** the type argument. For an anonymous class, the inferred type becomes the type argument of the generated subclass. The problem: inference can produce a **non-denotable type** — a type that exists in the compiler's type system but has **no way to be written in Java source**. Examples of non-denotable types are: - **Intersection types** like `Serializable & Comparable<...>` produced by combining bounds. - **Capture types** from wildcard capture (the compiler's internal `CAP#1` placeholders). If inference for the anonymous-class diamond produced such a type, the compiler would need to give the synthetic subclass a type it literally cannot name. Rather than handle this partially, Java 7 took the **conservative** route and forbade the diamond with anonymous classes entirely. So this was a compile error in Java 7-8: ```java Comparator<String> c = new Comparator<>() { ... }; // error before Java 9 ``` and you were forced to repeat the type: ```java Comparator<String> c = new Comparator<String>() { ... }; ``` ## What Java 9 changed (JEP 213, 'Milling Project Coin') Java 9 refined the rule instead of removing it. The diamond is now allowed with anonymous classes **when the inferred type argument is denotable** — i.e., can be written as an ordinary type name. The compiler does the inference; if the result is a normal type, it accepts the diamond: ```java // Java 9+ — compiles, infers String Comparator<String> c = new Comparator<>() { public int compare(String a, String b) { return a.length() - b.length(); } }; ``` If inference would yield a non-denotable type (an intersection or capture), the diamond is **still** rejected and you must specify the argument explicitly. So Java 9 didn't make it unconditional — it allowed the common, safe cases and kept the error only for the genuinely unrepresentable ones. ## Why it matters This is mostly an ergonomics fix: with Java 8 lambdas you'd usually avoid anonymous classes anyway, but for cases that *must* be anonymous classes (e.g. you need fields, multiple methods, or you're subclassing a class not a functional interface) the diamond now removes the repeated type argument. Understanding the 'denotable type' restriction also illuminates a deeper concept: the compiler's internal types are richer than what Java syntax can express, which is exactly why some inference results can't be used in every position. ## Key takeaways - Anonymous class = implicit named subclass needing a concrete type argument. - Java 7-8 banned the diamond there because inference could yield a non-denotable (unnameable) type. - Java 9 allows it when the inferred type is denotable; otherwise it's still an error and you specify the type.