11

I had a function in Java with method signature

public void myMethod (int someInt, String someString) 

in my abstract class and I had over-ridden it with method

public void myMethod (Integer someInt, String someString)

The over ride does not work. Is this an inconsistency ? I thought auto-boxing applied to method signature over-ride as well.

Arun R
  • 8,262
  • 5
  • 35
  • 45

6 Answers6

16

int and Integer are two different types. Autoboxing blurs the distinction at the source code level for the convenience of programmers, but does not change the fact that they are in fact two very different types.

As such, you can not @Override a method that takes an int with one that takes an Integer and vice versa.

Note that you should probably think twice before declaring a method to take an Integer instead of an int. Here's an excerpt from Effective Java 2nd Edition, Item 49: Prefer primitives to boxed primitives:

In summary, use primitives in preference to boxed primitive whenever you have the choice. Primitive types are simpler and faster. If you must use boxed primitives, be careful! Autoboxing reduces the verbosity, but not the danger, of using boxed primitives. When your program compares two boxed primitives with the == operator, it does an identity comparison, which is almost certainly not what you want. When your program does mixed-type computations involving boxed and unboxed primitives, it does unboxing, and when your program does unboxing, it can throw NullPointerException. Finally, when your program boxes primitive values, it can result in costly and unnecessary object creations.

There are places where you have no choice but to use boxed primitives, e.g. generics, but otherwise you should seriously consider if a decision to use boxed primitives is justified.

See also

Related questions

Community
  • 1
  • 1
polygenelubricants
  • 348,637
  • 121
  • 546
  • 611
  • 1
    +1: Very good answer, nailing not just this question but the other host of issues that cluster around it. – Donal Fellows Aug 02 '10 at 08:38
  • 1
    @Donal: well I've been known to go too far "off subject" on some answers, but I hope I hit just on target with this one. I was tempted to write about how subsignatures are specified for `@Override` purposes (JLS 8.4.2), but I managed to held back... this time... – polygenelubricants Aug 02 '10 at 08:41
  • I usually avoid prospective stuff unless it is either exactly relevant or the questioner has shown some expertise. The question, and at the level it was asked, is always my focus (except in comments; I'll witter on about irrelevant rubbish there. ;-)) – Donal Fellows Aug 02 '10 at 21:06
4

No, these two signatures define two different methods.

DixonD
  • 6,094
  • 4
  • 28
  • 49
2

They are absolutely not overridden but overload since the parameters are different. And JVM will choose the method to launch base on this: widen - boxing - var args...

For example, you have three methods

void add(long n) {} // call this method 1
void add(int... n) {} // call this method 2
void add(Integer n) {} // call this method 3

and when you invoke:

int a = 5;
add(a);

the method 1 will be invoked.

Truong Ha
  • 9,070
  • 10
  • 35
  • 45
1

The reason the override doesn't work is because Integerand int are two different things. Integer is an object, whereas int is a primitive type. Java does the implicit typecasting for you. For example:

int myInteger = new Integer(5);

Will create a primitive int type called myInteger with a value of 5. As the Javadoc says,

"The Integer class wraps a value of the primitive type int in an object."

JBirch
  • 629
  • 1
  • 4
  • 12
0

You are correct that this scenario will not work because Java provides the functionality of the autoboxing, so at runtime JVM can not decide which method to call because it can call both method as both method fits for the argument type. So I think it will give an error or will choose either method randomly..... Just run it and see.....

Darshan Prajapati
  • 793
  • 1
  • 9
  • 31
0

int and Integer are two different types in JAVA.Although autoboxing specifies the distinction at the source code level, but does not change the eternal fact that they are in fact two very different types.

Neel
  • 429
  • 7
  • 17