This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Methods cannot be overloaded based on the return types alone. That makes sense as the compiler will not be in a position to differentiate which method is invoked.
In the case of overriding something similar is applicable. Why cannot a method which is overriding in a derived class not permitted to have a different return type? The compiler will be able to make out the overriding method but then why does it care about the return types matching?
Jesper is absolutely right. Just one note:
From Java 5 you can use covariant return types.
It means that a method in a subclass may return an object whose type is a subclass of the type returned by the method with the same signature in the superclass.
Which can be of great use in methods like clone(). For instance, Date.clone() could have returned a Date, thereby removing the need for casts. Sun however were either lazy or they simply forgot to change the declared return types for just about every method that could have used it. It's not like returning Date from Date.clone() would have broken any code, it just would have made all the casts unnecessary.