Reference to method is ambiguous??????

[Michael Lin]

class one{
void method(int e){System.out.println("one");}
//if this method private, no compile error
}
class two extends one{
void method(double l){System.out.println("two");}
//void method(int e){System.out.println("one");}
public static void main(String []a){
int i=5;
two r=new two();
r.method(i);
}
}
//why this code give error: Reference to method is ambiguous
//but if use private or move the method into the two, all fine??
can anybody explain this, thanks !

[Bharatesh H Kakamari]

Question 1 :
If private no error :
If you declare a method as private then the subclass does not inherits this method. But you can provide the implementation of this method having same return type and parameters. Although this is allowed during compile time and also run time, it concept is not called overriding. But it works!
Question 2 :
// error for ambiguity
I am not getting this error :
Here is the code that is unblocked but works !

class one{ 
void method(int e){System.out.println("one");} 
//if this method private, no compile error
}
class two extends one{ 
void method(double l){System.out.println("two");}
void method(int e){System.out.println("one");}
// THIS IS WORKING AFTER UNBLOCKING
public static void main(String []a){
int i=5;
two r=new two();
r.method(i);
}
}

[Sahir Shah]

The method(double d) can be called by passing an int value and
the method(int i) can be called by passing an int value.
Hence an ambiguous situation arises. The compiler will not accept
this. However if you change the method call to one with a double
it will compile because a double cannot be converted to int during method call. I do not know why it works when both methods are moved to the same class. It shoudnt make a difference. Perhaps it is a bug, either this way or the other. Let me try posting a bug report and see what happens.
Rgds
Sahir
[This message has been edited by Sahir Shah (edited December 12, 2000).]

[Aparna Narayanan]

Hi Michael,
A very good and interesting question, indeed. It's a subtle point. These are the rules you need to look upon:
1. A class can have two methods with the same name, but with different set of arguments/arg types[overloaded methods] in any of the following 3 cases:
a. both methods are in the same subclass
b. both methods are in the super class
c. one is in superclass and one in subclass
2. If there are two methods with the same name, one in the superclass and one in the subclass, then, the method in the subclass should be given more preference.
3. If there are two methods available with the same name in a class, the method that is called is the method which has arguments that most exactly matches with the set of arguments passed upon.
Now, let us look at your example:
In your main, you call the subclass method with int argument. Now, since by Rule (2), the subclass method with double argument should be given more preference.
But, by Rule (3), the superclass method which takes int argument itself should be given more preference.
Hence, it is now not able to decide between Rules 2 and 3. Hence it results in a compilation error complaining of ambiguity.
Now, consider the following code:
<CODE>
class one
{
void method(float e)
{
System.out.println("one - float");
}
}
class two extends one
{
void method(int e)
{
System.out.println("two - int");
}
void method(String s)
{
System.out.println("two - string");
}
public static void main(String []a)
{
int i=5;
two r=new two();
r.method("hi");
r.method(i);
}
}
</CODE>
In the above case, you call subclass method with int as argument. Here none of the rules clash with each other. Hence, the subclass method with int argument is called.
Similarly, consider the following code:
<CODE>
class one
{
void method(int e)
{
System.out.println("one - int");
}
}
class two extends one
{
void method(int e)
{
System.out.println("two - int");
}
void method(String s)
{
System.out.println("two - string");
}
public static void main(String []a)
{
int i=5;
two r=new two();
r.method("hi");
r.method(i);
}
}
</CODE>
Here, too, there is no ambiguity as none of the 3 rules clash with one another, hence, it doesn't give a compilation error.
Hope I am clear. A good question, indeed!
Thanks,
Aparna

[Randall Twede]

it opened my eyes. i mean how does it decide which rule to follow? Since this is certainly an error on the programmers part it is a feature of java not a bug.
[This message has been edited by Randall Twede (edited December 12, 2000).]

[Aparna Narayanan]

Hi Randall,
Mebbe I'll have to be more clear.
Take Michael's code wherein he's specified
method(int) in superclass
and
method(double) in the subclass.
When he creates an object of the subclass and calls the method(i) this matches most exactly with that of the superclass constructor
method(int) [So by rule 3, it has to call the superclass constructor with int parameter]
but then, by rule 2, a subclass constructor has to be given more preference if the argument is able to be converted to one of the formal parameter types of the subclass. Now, since an int can be converted to a double, it can call the subclass constructor with double parameter, but the problem is that it is NOT AN EXACT MATCH. Hence, an ambiguity arises.
But, consider the examples I have provided in my previous post. In both of them, the rules 2 and 3 are taken care of, the subclass constructors themselves are more exact as far as the actual arguments are concerned. Hence, these examples would compile/execute fine.
Hope I am clear now.
Thanks,
Aparna