A really nice question indeed. While the JLS explains why this is compiling, I don't understand why they did it that way.
JLS wrote:The notion of subsignature 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.
I can understand this being allowed if you are inheriting raw version of a library which now has generics added. So for example this class written in JDK 1.4 should compile and run on > JDK 5:
Of course this will compile as I'm implementing raw version of Comparable, so parameter to
compareTo would be Object. But as soon as I declare my class as Generic, the compiler should enforce me to implement Comparable of that type
The above code compiles fine. I'm wondering why because, A) will there be any backward compatibility problems if it's not allowed (the class is already using Generics, so shouldn't it use Generics properly in implementing methods as well?), B) this can create confusion if I add another compareTo method which takes Employee instance
Here the
compareTo(Employee emp) is just an overloaded method. If I create some instances of
Employee<Employee>, add them to a list and sort the list, the
compareTo(Object) method will be called:
So if I'm sorting the list the
compareTo(Object) method is called, but if call the method directly with another
Employee instance, then
compareTo(Employee) is called which can be confusing...