The Java Language Specification, Third Edition

CLASSES Method Signature 8.4.2
Two method or constructor declarations M and N have the same argument types
if all of the following conditions hold:
• They have the same number of formal parameters (possibly zero)
• They have the same number of type parameters (possibly zero)
• Let be the formal type parameters of M and let be
the formal type parameters of N. After renaming each occurrence of a Bi in N’s
type to Ai the bounds of corresponding type variables and the argument types
of M and N are the same.
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.
DISCUSSION
The notion of subsignature defined here is designed to express a relationship between two
methods whose signatures are not identical, but in which one may override the other.
Specifically, it allows a method whose signature does not use generic types to override
any generified version of that method. This is important so that library designers may freely
generify methods independently of clients that define subclasses or subinterfaces of the
library.
Consider the example:
class CollectionConverter {
List toList(Collection c) {...}
}
class Overrider extends CollectionConverter{
List toList(Collection c) {...}
}
Now, assume this code was written before the introduction of genericity, and now the
author of class CollectionConverter decides to generify the code, thus:
class CollectionConverter {
List toList(Collection c) {...}
}
Without special dispensation, Overrider.toList() would no longer override CollectionConverter.toList().
Instead, the code would be illegal. This would significantly
inhibit the use of genericity, since library writers would hesitate to migrate existing code.
DRAFT
213