Explain the JLS rule that governs the 'same erasure' overload clash and what 'override-equivalent' means.

## What the rule actually says From the Java Language Specification (JLS, the official Java rules): *'It is a compile-time error for a class to declare two methods with override-equivalent signatures.'* And separately: two methods have the *same signature* if they have the same name and *argument types*, where argument-type comparison is done after considering type-variable substitution; but for the *clash* check the decisive notion is the **erasure** of the parameter types. ## Defining each term - **Signature**: method name + ordered list of formal parameter types. (Return type and `throws` are excluded.) - **Erasure**: the transformation that removes generics from a type. Rules: a parameterized type `C<T1..Tn>` erases to the raw type `C`; a type variable erases to the erasure of its *leftmost bound* (`<T>` with no bound → `Object`, `<T extends Number>` → `Number`); arrays erase component-wise; everything else stays. So `List<String>` → `List`, `Map<K,V>` → `Map`, `T` (unbounded) → `Object`. - **Subsignature**: signature A is a subsignature of B if A equals B, or A equals the *erasure* of B. This deliberately bridges the generic and raw worlds (so a generic method can override/match a raw one). - **Override-equivalent**: two signatures where one is a subsignature of the other. If two *declared* methods in one class are override-equivalent, that is the illegal clash. ## Worked example ```java class C { void m(List<String> a) {} void m(List<Integer> a) {} // ERROR } ``` Erase parameters: both → `m(List)`. Each signature is a subsignature of the other (they share the same erasure), so they are override-equivalent → compile error: *'name clash: ... have the same erasure'*. ## Why type variables follow the same logic ```java <T> void m(T t) {} void m(Object o) {} // ERROR — T erases to Object ``` `<T>` (unbounded) erases to `Object`, so `m(T)` and `m(Object)` collide. ## Connection to bridge methods When a generic class is subclassed/implemented, the compiler may emit a synthetic **bridge method** so that the erased (raw) caller and the generic override line up. The same-erasure machinery is what makes bridge methods necessary and also what can cause cross-class clashes (e.g. accidentally overriding the bridge). Understanding the rule is understanding why bridges exist. ## What is NOT considered - **Return type** — irrelevant to the signature, so it can never resolve a clash. (One narrow exception: covariant return types are allowed *only when one method legitimately overrides another*, never to disambiguate two same-class declarations.) - **Type-parameter names** — `<T> void m(T)` and `<U> void m(U)` are the same after renaming. - **Bounds in the source** — `List<? extends Number>` and `List<Integer>` both erase to `List`. ## Practical implication for API design Because the rule is erasure-based, you cannot design an API that overloads purely on type arguments. If callers should pick behavior by element type, use distinct method names, a marker parameter (`Class<T> type`), or a single generic method. This is a deliberate, accepted limitation of Java's erasure-based generics.