Why difference in types of arguments in overridden method (one is primitive and other is wrapper) is not allowed?

Question

I have started with JAVA programming recently and have one question to ask. Let's say I have one SuperClass and one SubClass which extends SuperClass and try to Override a method defined in SuperClass as follows:

  public class SuperClass{
    public void method1(int val){
      System.out.println("This is method in SuperClass.Val is:" + val);
      }
  }

I try to extend the SuperClass in my SubClass and override the method with only one exception, instead of type int declared in method1, I use the type for the argument as Integer, as follows:

  public class SubClass extends SuperClass{
    @Override 
    public void method1(Integer val){     ///compiler gives an error

     }
  }  

This declaration of SubClass method is not allowed by the compiler(I am using eclipse IDE). Why is this so? Integer is essentially wrapper of int then why such a declaration is prohibited?

Thanks

Answer 1

The formal explanation, as you probably already understand, is that the two functions have different signatures, (as Andrew Tobilko has already pointed out,) so one may not override the other.

So, I presume that by asking this question, what you really mean to ask is "why is this so", or "why can't the compiler figure things out so as to allow me to do this".

So, the practical explanation is as follows:

This is because you may have some method somewhere, (of some unrelated class even) which accepts a SuperClass as a parameter, and attempts to invoke its method1() like this:

public void someMethod( SuperClass s )
{
    s.method1( 7 );
}

When the compiler finds this, it will pass 7 as a parameter to method1(), it will not pass a wrapped 7. However, s may not really be an instance of SuperClass, it may be an instance of SubClass, like this:

/* some code somewhere */
someMethod( new SubClass() );

This is valid because there is a principle in OOP known as the Liskov Substitution Principle which says that

if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may substitute objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.).

_{This is the same principle which allows you to assign a new ArrayList<String>() to a variable of type List<String>, and without it, nothing would work in OOP.}

So, the compiler would have to pass a plain primitive 7, but the receiving method of SubClass would be expecting a wrapped 7, and that would not work. So, the language stipulates that an implicit conversion of this kind is invalid, to ensure that nonsensical situations of this kind may not arise.

Amendment

You might ask, "why would it not work?" The answer is that primitives in java correspond to machine data types of the underlying hardware, while wrapped primitives are objects. So, on the machine stack, a 7 would be represented by a machine word with the value of 7, while a wrapped 7 would be represented by something like 0x46d7c8fe, which would be a pointer to an object which contains the wrapped 7.

Answer 2

It is just because you have added @Override syntax above the method public void method1(Integer val) which asks compiler to look for the method with same signature in the base class which it can not find, thus it gives compile time error stating The method method1(Integer) of type SubClass must override a superclass method.

To understand the problem you asked

Integer is essentially wrapper of int then why such a declaration is prohibited?

Just because in any class you can declare method with these signatures

class SuperClass
{
    public void method1(int val){
        System.out.println("This is method in SuperClass.Val is:" + val);
    }

    public void method1(Integer val){
        System.out.println("This is method in SuperClass.Val is:" + val);
    }
}

The above declaration is valid and therefore the @override will try to match the method with exact signature in base class.

Answer 3

Why should it matter that Integer is a wrapper for int? They are still different types. You can have to methods with same name, that just differ by one having a primitive type and the other the matching wrapped type.

The only relation between int and Integer is: the compiler insert a conversion from one to the other when in any situation one is given but the other required.

So when you have a reference to the super type and call method1 the compiler generates byte code that essentially passes a primitive. If at runtime you use an actual class of SubClass, the overridden method won't match that call.

Of course the compiler could be written in a style that allows for this kind of overrides, but it would cause other problems:

If the decision was made at runtime, calling overriden methods would become expensive to to boxing/unboxing and checks, they might even trigger NullPointerExceptions

If done by converting everything to the boxed type at compile time, such calls would trigger constant boxing unboxing.

Also this would forbid constructs where you have a method that is overloaded to either take a type parameter or a primitive, because the type parameter might end up being the boxed type for that primitive, resulting to both methods being the same.

Answer 4

Integer and int are different.You could change Integer to int,or remove the "@Override"