Doubt in Overload and Override

[sureshkumar settu]

I have a doubt on overridding or loading.

class X{
protected int process(int x){}
}
class Y extends X{
protected long process(int x){} // this is overload or override??
protected int process(long x){} // this is overload or override??
}

I have this doubt for a long time. i am confused please any one help.

[Mohamed Sanaulla]

Return types are not included in method overloading. So it doesn't matter if the return types are similar or different when overloading methods.

[Matthew Brown]

Unless the method signature (which is made up of the name and argument types) is identical, then it can't be overriding.

So....the second method is definitely an overload, because the argument types are different.

The first method would be overriding, because they have the same type. The problem is it doesn't compile. The return value isn't part of the signature, but there are very strict restrictions on when you can change the return type when overriding. You can only narrow the return type, whereas in this case you're trying to widen it.

Consider this case:

X x = new Y();
int input = 10;
int output = x.process(input);

The third line should be perfectly valid. X.process(int) returns an int. We shouldn't have to worry about what subtype of X we have (this is the Substitution Principle). But Y.process(int) returns a long. So we end up assigning a long to an int variable without an explicit cast, and that's not allowed. So the compiler will stop us overriding like that in the first place.

[marc weber]

Here are some references that should help...

Overloading: Java Tutorial - Defining Methods

Overriding: Java Tutorial - Overriding and Hiding Methods

[zameel amjed]

both are not overriding method because arguments are not same type

to be a overided method Argument and Return type must match and the access level must be match or less restrictive
and throwing exception should not be a new or broder type

in your code

class X{
protected int process(int x){}
}
class Y extends X{
protected long process(int x){} // not overiding method.return type must be matched. you may use a casting to invoke flot and making int as return type to make this overriding
protected int process(long x){} // not overriding as the Argument list not matched.
}

[Campbell Ritchie]

Please look at Matthew Brown's post, zameel amjed.

[sureshkumar settu]

Thanks ranchers, you rocks.

I have this doubt for a long time. I think i am clear now

what about this overriding

class X{
protected long process(int x){}
}
class Y extends X{
protected int process(int x){} // as per your explanation i think i understand it well, if i am right here. this is legal overriding
}

even though superclass return type is long we can return int type in our sub class.

because
....
XX a = new X();
XY b = new Y();
long result=0;
result=a.process(0); // compiles and run fine
result=b.process(0); // compiles and run fine
....

Am i right here???

[Matthew Brown]

sureshkumar settu wrote:
what about this overriding

class X{
protected long process(int x){}
}
class Y extends X{
protected int process(int x){} // as per your explanation i think i understand it well, if i am right here. this is legal overriding
}

...

Am i right here???

Hi Sureshkumar,

My first thought was yes, you're right. Unfortunately, after further thought and a quick test, I've realised my original explanation was missing something.

What I said about narrowing the return type being allowed is true for reference types. For example:

class A {
    protected Object doSomething(int x) {...}
    protected Integer doSomethingElse(int x) {...}
}

class B extends A {
    // The following is OK, as per my explanation earlier
    protected Integer doSomething(int x) {...}
    
    // The following is _not_ OK, based on the same explanation
    protected Object doSomethingElse(int x) {...}
}

But primitives are different. In this case the return type has to be exactly the same. And I think I've realised at least one reason why this is the case. It's to do with autoboxing. Do you remember the rule that the compiler will box-then-widen a value (so an int can be converted to an Object), but it will not widen-then-box (so an int cannot be converted to a Long)? Now consider this, based on your last example:

X x = new Y();
Long value = x.process(10);

X.process returns a long, so it can be happily boxed to a Long. But Y.process returns an int. Which can't be converted to a Long. Oops!

Which all goes to show one thing. If you're really in doubt about how something works in a programming language - try it!

[sureshkumar settu]

Mathew,

You missed some thing i didn't mention Long (object) that is long (primitive). I think you missed it.

I know about box - and - widen rules that's not a problem.

my doubt is simple

can i put sub class return type as int when super class return type is long (primitive).

[Rob Spoor]

No you can't. To be honest, that surprises me. Java 5.0 introduced covariant return types, where the return type of an overridden method can be narrower. For example, if the return type of the method in the super class is Object, the return type of the overridden method in the sub class can be String instead.

I've already tried this yesterday but this does not apply to primitives. So even if all int values will fit into a long, it's still not allowed to change the return type into int if the return type of the method in the super class is long.

Of course you can still return the value of an int variable, but the return type must remain long.

[Matthew Brown]

sureshkumar settu wrote:You missed some thing i didn't mention Long (object) that is long (primitive). I think you missed it.

I know about box - and - widen rules that's not a problem.

my doubt is simple

can i put sub class return type as int when super class return type is long (primitive).

I didn't miss it. My point about boxing is to illustrate why we can't change the return type in the subclass if the subclass is primitive. Like Rob, I was a bit surprised that you can't, but then realised that to allow it would contradict the box-and-widen rules (as my example demonstrates).

There may be other reasons as well, but that one reason is enough to rule it out.

[sureshkumar settu]

Still i feel something am missing.

If a method in super class returns Object means we can use any (subclass of Object) in our subclass

i.e.
class X{
protected Object process(int x){}
}
class Y extends X{
protected Integer process(int x){} // It is possible
}

but for primitives we can only return the same type which super class methods return. we are not supposed to return any other type.
i.e.
class X{
protected int process(int x){}
}
class Y extends X{
protected Integer process(int x){} // This too Not possible
}

or

[Matthew Brown]

But really, a much better idea than to take our word for it is to try it out. Try compiling your example, see if it works.