How can a generic superclass cause a 'same erasure' clash in a subclass, and what role do bridge methods play?

## Setup: erasure across inheritance A *generic* type's type variable is erased to its bound. So: ```java class Box<T> { void add(T t) {} } // erased: void add(Object) ``` When a subclass *binds* the type variable to a concrete type and overrides the method: ```java class StringBox extends Box<String> { @Override void add(String s) {} // erased: void add(String) } ``` Now there is a mismatch: the supertype's erased method is `add(Object)`, but the override's erased signature is `add(String)`. A caller holding a raw `Box` (or `Box<String>` compiled against the generic view) expects to call `add(Object)`. If only `add(String)` existed in `StringBox`, polymorphism would break for the erased call. ## Bridge methods (the compiler's fix) To reconcile this, the compiler generates a synthetic, bridge-flagged **bridge method** in `StringBox`: ```java // generated by the compiler, not in source: void add(Object o) { add((String) o); } ``` The bridge has the *supertype's erased signature* `add(Object)`, performs the cast, and forwards to the real override `add(String)`. This keeps both the raw/erased call path and the generic override working. Bridges are why a `ClassCastException` can surface from a line you 'never wrote' when raw types smuggle in a wrong-typed argument. ## How a clash appears Because bridges occupy real erased method slots, a subclass can collide with them or with inherited erased signatures: 1. **Declaring the bridge's signature yourself** ```java class StringBox extends Box<String> { void add(String s) {} void add(Object o) {} // clashes with the generated bridge add(Object) } ``` The compiler wants to generate `add(Object)` as a bridge but you already declared `add(Object)` — *name clash: ... have the same erasure*. 2. **Two supertypes whose methods erase identically** ```java interface A { void f(List<String> x); } interface B { void f(List<Integer> x); } class C implements A, B {} // f(List) vs f(List) — cannot implement both ``` No single method can satisfy both erased contracts → clash. 3. **Inherited generic + own raw method** Declaring a method whose erasure equals an inherited generic method's erasure produces the same override-equivalence error. ## The governing rule (recap, generalized) It is a compile-time error if a class ends up with two *override-equivalent* methods (same name, same erased parameter types), counting **generated bridge methods** as real members. That is the unifying principle behind every case above. ## Diagnosing in practice - Read the **erased** signatures, not the generic source. Mentally apply: parameterized type → raw type; type variable → leftmost bound. - Use `javap -p -v` on the `.class` to *see* the synthetic bridges (`ACC_BRIDGE`, `ACC_SYNTHETIC` flags) and confirm which descriptors actually exist. - For the two-interface case, you genuinely cannot implement both in one class — the design must change (separate adapters, or non-clashing method names). ## Why Java accepts this complexity Erasure was chosen for binary compatibility with pre-generics code and to avoid per-instantiation code bloat. Bridge methods are the price that preserves polymorphism under erasure. The clashes are emergent constraints of that design; senior/principal engineers design class hierarchies and interfaces so that erased signatures never collide, and reach for `javap` when a puzzling 'same erasure' or unexpected `ClassCastException` appears.