The rules in 8.4.8.4 are concerned only with override-equivalent inherited methods. But similar scenarios can arise when an inherited method has a subsignature of a declared method:

class C<T> { void m(T c) {} }
class D extends C<Class> { void m(Class<String> c) {} }
// m(Class) is a subsignature of m(Class<String>), but not vice versa

(Note that there would be an erased-signature clash if there were not a generic instantiation, and C.m were declared with signature m(Class); this is a pretty unusual scenario.)

The declaration of D is currently legal, which I guess could be argued as okay, but it's not clear why this situation is "better" than the case of inheriting two override-equivalent methods. And if another class extends D, an error would then occur, despite the child not being "at fault" (javac doesn't actually produce any error).

Specific cases to consider:
- Two concrete instance
- static vs. non-static
- Concrete instance vs. abstract (error in JLS 8)
- Two abstracts that are not return-type-substitutable

(The "considered to override" logic in JLS 7 8.4.8.4 should certainly not allow a superclass method to override a subclass method. Fortunately, JLS 8 replaces this with a more refined definition of inheritance in 8.4.8.1, so it's no longer a problem.)