Original issue created by cpovirk@google.com on 2013-07-03 at 01:22 AM
Occasionally, a user who intends to define a class that implements a specialized generic interface will inadvertently write "<String>" twice, once for the interface he's implementing and once for his own class. For example, note the "MyComparator<String>" below:
static class MyComparator<String> implements Comparator<String> {
@Override public int compare(String a, String b) {
return compareStrings(a, b);
}
}
This can lead to confusing errors like "incompatible types required: String found: java.lang.String," as in this StackOverflow question:
An error-prone check for type parameters named "<String>" would probably catch 95% of these errors. The check might get a few more percent by looking for other common JDK class names, but I suspect that most of the remaining 5% would instead happen with custom user classes.
(In an ideal world, I'd be inclined to reject any type parameter with a ClassNameStyle name, conveniently catching all these errors, but that's unrealistic.)
Here are a couple searches that turn up instances of this problem in Google code. (One of those instance is about to be fixed. That fix is what led me to file this feature request.)
Original issue created by cpovirk@google.com on 2013-07-03 at 01:22 AM
Occasionally, a user who intends to define a class that implements a specialized generic interface will inadvertently write "<String>" twice, once for the interface he's implementing and once for his own class. For example, note the "MyComparator<String>" below:
static class MyComparator<String> implements Comparator<String> { @Override public int compare(String a, String b) { return compareStrings(a, b); } }
This can lead to confusing errors like "incompatible types required: String found: java.lang.String," as in this StackOverflow question:
http://stackoverflow.com/q/8443892/28465
An error-prone check for type parameters named "<String>" would probably catch 95% of these errors. The check might get a few more percent by looking for other common JDK class names, but I suspect that most of the remaining 5% would instead happen with custom user classes.
(In an ideal world, I'd be inclined to reject any type parameter with a ClassNameStyle name, conveniently catching all these errors, but that's unrealistic.)
Here are a couple searches that turn up instances of this problem in Google code. (One of those instance is about to be fixed. That fix is what led me to file this feature request.)
'(class|interface) \w+<String>'
'(class|interface) \w+<[A-Z][a-z]\w+>\s+implements Comparator'