Hello folks, Now this situation has me completely foxed. I have following code:
When I try to compile this program under JVM 1.3 I am getting compiler error as follows "Java0613.java": Error #: 304 : reference to method1 is ambiguous; both method method1(int) in class anshul.Java06131 and method method1(double) in class anshul.Java0613 match at line 28, column 10 When I move the method with signature as double to superclass then it doesn't complain about the method ambiguity and the program executes nicely. Comments invited .
You aren't overriding the method, you are OVERLOADING it. But there's still something fishy about it. It is OK for the compiler to report an ambiguity, I suppose, because the value passed (3) matches the signatures of both the int and double methods, one in the subclass and one in the superclass. (See JLS 5.3 and 5.1.2 for the relevant parts on widening conversions.) However, moving both methods to the superclass shouldn't then RESOLVE the ambiguity in favor of the (int) method! (Unless somehow having them both in the same method helps the compiler disambiguate by figuring that the (int) version is more specific now, but why should the overloaded method being inherited make a difference?)In fact, Sections 15.12.1, 15.12.2, and 184.108.40.206 of the JLS suggest that the ambiguity should still exist. If the (int) method in the superclass is applicable and accessible, so should the (double) method be! I get the same error as you with 1.3.1--but with the fastjavac compiler, the error I get is *different*, namely "No method found matching method1(int)". I think this is a strange situation, possibly a compiler bug. Perhaps someone else can verify this. I simplified your code to isolate the problem, and used the following:
The error I got at line 24 was "No method found matching amethod(int)." Again, the way I interpret the relevant sections of the JLS (see 15.12.1 and 15.12.2), there should be no problem, as it is stated in 220.127.116.11 that "method definitions inherited from superclasses and superinterfaces are included in this search [for an appropriate method signature]." In my case, what seems to be happening is that the superclass method is somehow getting "shadowed" by the method of the same name as the subclass, which shouldn't happen. (Removing the method from the subclass altogether or moving it to the superclass "solves" the problem here too--the (int) version of the method gets called.) Does anyone else come across this? What happens when you compile it on JDK 1.2.1 or on non-Sun compilers? [I got the same behavior with jikes, i.e. ambiguous when the double and int versions are in different classes, and no problem when both are in the superclass, with the int version being selected when passed an int.] Am I misreading the JLS? Compiler bug in both cases? Thanks. [This message has been edited by Ranjan Chaudhuri (edited June 20, 2001).] [This message has been edited by Ranjan Chaudhuri (edited June 20, 2001).] [This message has been edited by Ranjan Chaudhuri (edited June 20, 2001).]
Joined: Apr 17, 2001
thanks ranjan, it is overloading and not overriding.
hi in case of overloading what happens is, the most specific method is chosen that is if u have a mehtod taking an int as a parameter and another taking a double and if u pass int as a parameter, the method that takes the int as parameter will be called. (when the methods are in the same class) in the case shown in the above code we are overloading the method in subclass and calling the method with reference to the object with an int parameter now we have a method taking double as a parameter in the subclass and an int parameter will fit into it. but it also has an int method inherited from superclass thus the ambiguity. it is something like when the subclass has a satisfying method in its own class it does not understand why it should use it from the super class
Joined: May 22, 2001
Hi, Intuitively, I agree and that's what I always assumed. But I would be much happier if someone could show me (preferably using the JLS), why the (int) version is more specific than the (double) version in the above case, or even in the simpler one below. It's probably something as simple as the fact that requiring a widening conversion makes the (double) version less specific. BUT IN THAT CASE, this should be so even if the (int) version is in the superclass and the (double) version is in the subclass, no? I keep thinking there's some sort of inconsistency here. I think looking at the JLS too closely has confused me.
Thanks. [This message has been edited by Ranjan Chaudhuri (edited June 20, 2001).]