I am just learning Java, and am not a practicing programmer.

The book I am following says that when overriding a method, the argument types must be the same, but the return types can be polymorphically compatible.

My question is why can't the arguments passed to the overriding method not be a subclass type of the super-type expected?

In the overloaded method, whatever method I call on the object is guaranteed to be defined on the object.

Notes on suggested duplicates:

The first suggestion appears to be about class hierarchy and where to put functionality. My question is more focused on why the language restriction exists.

The second suggestion explains how to do what I'm asking, but not why it has to be done that way. My question is focused on the why.

  • 1
    asked and answered in prior question: "This is generally regarded as failing the Liskov Substitution Principle (LSP), because the added constraint makes that the base-class operations are not always appropriate for the derived class..."
    – gnat
    Commented Dec 24, 2014 at 16:05
  • 1
    possible duplicate of Making subclass more type-specific with accessors
    – user22815
    Commented Dec 24, 2014 at 16:07
  • @gnat the question is not whether requiring more specific subtypes for arguments violates some computer principle, the question is whether is it possible, which edalorzo answered.
    – user949300
    Commented Dec 24, 2014 at 20:54
  • possible duplicate of Template pattern with varying input type in overridden method
    – gnat
    Commented Dec 24, 2014 at 21:57
  • But the answer by @edalorzo is much more well explained.
    – Truong
    Commented Sep 15, 2021 at 10:09

2 Answers 2


The concept you initially refer to in your question is called covariant return types.

Covariant return types work because a method is supposed to return an object of certain type and overriding methods may actually return a subclass of it. Based on the subtyping rules of a language like Java, if S is a subtype of T, then wherever T appears we can pass an S.

As such it is safe to return an S when overriding a method that expected a T.

Your suggestion to accept that an overriding a method uses arguments that are subtypes of those requested by the overridden method is much more complicated since it leads to unsoundness in the type system.

By one hand, by the same subtyping rules mentioned above, most likely it already works for what you want to do. For instance

interface Hunter {
   public void hunt(Animal animal);

Nothing prevents implementations of this class from receiving any kind of animal, as such it already satisfies the criteria in your question.

But let's suppose we could override this method as you suggested:

class MammutHunter implements Hunter {
  public void hunt(Mammut animal) {

Here's the funny part, now you could do this:

AnimalHunter hunter = new MammutHunter();
hunter.hunt(new Bear()); //Uh oh

As per the public interface of AnimalHunter you should be able to hunt any animal, but as per your implementation of MammutHunter you only accept Mammut objects. Therefore the overriden method does not satisfy the public interface. We just broke the soundness of the type system here.

You can implement what you want by using generics.

interface AnimalHunter<T extends Animal> {
   void hunt(T animal);

Then you could define your MammutHunter

class MammutHunter implements AnimalHunter<Mammut> {
   void hunt(Mammut m){

And using generic covariance and contravariance you can relax the rules in your favor when necessary. For instance we could make sure that a mammal hunter can only hunt felines in a given context:

AnimalHunter<? super Feline> hunter = new MammalHunter();
hunter.hunt(new Lion());
hunter.hunt(new Puma());

Supposing MammalHunter implements AnimalHunter<Mammal>.

In that case this would not be accepted:

hunter.hunt(new Mammut()):

Even when mammuts are mammals it would not be accepted due to the restrictions on the contravariant type we are using here. So, you can still excercice some controll over the types to do things like the ones you mentioned.

  • Thank you for the explanation, however it will be way clearer if you'v chose something else other than Mammal, Mamut etc. :)
    – amd
    Commented Mar 10, 2021 at 13:26

The problem is not what you do in the overriding method with the object given as argument. The problem is what is the type of arguments the code using your method is allowed to feed to your method.

An overriding method must fulfill the contract of the overridden method. If the overridden method accepts arguments of some class and you override it with a method that accepts only a subclass, it doesn't fulfill the contract. That is why it is not valid.

Overriding a method with a more specific type of argument is called overloading. It defines a method with the same name but with a different or more specific type of argument. An overloaded method is available besides the original method. Which method is called depends on the type known at compile time. To overload a method you have to drop the @Override annotation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.