FULL PRODUCT VERSION :
java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b07)
Java HotSpot(TM) Client VM (build 17.0-b17, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.0.6001]

A DESCRIPTION OF THE PROBLEM :
I think this is a regression of Bug 6182950. The following compiles, but it should not:

import java.util.List;
class X {
    int f(List<String> l) {return 0;}
    double f(List<Integer> l) {return 0;}
}



A) However, he original report seems to reason incorrectly.
Section 8.4.3.3 does not apply because
the signature of f(List<String>) IS a subsignature of f(List<Integer>) (and vice-versa)
according to section 8.4.2:
"The signature of a method m1 is a subsignature of the signature of a method m2 if either
  - m2 has the same signature as m1, or
  - the signature of m1 is the same as the erasure of the signature of m2"

The 2nd criterion applies, I think (see section "4.6 Type Erasure"):

 - The erasure of a parameterized type (��4.5) G<T1, ... ,Tn> is |G|.
 - The erasure of a method signature s is a signature consisting of the same name as s, and the erasures of all the formal parameter types given in s.

Thus f(List<String>) and f(List<Integer>) both become f(List) and thus, m1 is a subsignature of m2 and vice versa (they are override-equivalent).

(Note that the return type is not part of a method's signature!)



B) The code still must not compile. The reason can be found in "8.4.2 Method Signature":
"It is a compile-time error to declare two methods with override-equivalent signatures (defined below) in a class."

"Two method signatures m1 and m2 are override-equivalent iff either m1 is a subsignature of m2 or m2 is a subsignature of m1."

Since both methods have the same name and override-equivalent signatures and are in the same class, the code should not compile. (Eclipse Helios correctly reports this.)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile the following code:

import java.util.List;
class X {
    int f(List<String> l) {return 0;}
    double f(List<Integer> l) {return 0;}
}

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Code does not compile:
Error:  line (4) name clash: f(java.util.List<java.lang.String>) and f(java.util.List<java.lang.Integer>) have the same method name with override-equivalent signatures.

ACTUAL -
No error. The code compiles correctly. (and behaves correctly, because the JVM can still distinguish the methods by their return types, whereas the language spec prohibits it).

REPRODUCIBILITY :
This bug can be reproduced always.