aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Resolving most specific method Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Resolving most specific method" Watch "Resolving most specific method" New topic
Author

Resolving most specific method

Gopal Shah
Ranch Hand

Joined: May 17, 2003
Posts: 65
Hello friends,
For finding the most specific method among a set of possible methods, the rule says:
method1(t1, t2 ... tn) defined in T is more specific than
method2(u1, u2 ... un) defined in U
if the following conditions r satisfied
1> T can be converted to U by method invocation conversion
2> t1, t2 ... tn can be converted to u1, u2 ... un by method invocation conversion.
Somehow the rule doesn't seem to work when T & U r interfaces.
The following code compile's without error
***********************************************************

***********************************************************
While the following code as expected gives compilation error for having ambiguous method calls
*********************************************************

***********************************************************************
[ Jess added UBB [code] tags to preserve whitespace, check 'em out! ]
[ September 05, 2003: Message edited by: Jessica Sant ]
Gopal Shah
Ranch Hand

Joined: May 17, 2003
Posts: 65
Sorry for the lack of indentation & improper "Print" statements. I have posted this message quite hastily.
Alton Hernandez
Ranch Hand

Joined: May 30, 2003
Posts: 443
I don't see anything wrong with these codes. Both will compile.
[ September 05, 2003: Message edited by: Alton Hernandez ]
Gopal Shah
Ranch Hand

Joined: May 17, 2003
Posts: 65
No the second code doesn't compile becoz
-> Abc can be converted into Xyz but long cannot be converted into int
-> int can be converted into long but Xyz cannot be converted into Abc
Marlene Miller
Ranch Hand

Joined: Mar 05, 2003
Posts: 1391
Gopal, there is a similar problem for static methods, instead of interfaces, described in the Java Bug Database:
http://developer.java.sun.com/developer/bugParade/bugs/4723909.html
Bug Id: 4723909
Synopsis: class methods do not conform to JLS 15.12.2.2 definition of most specific method
Reported Against: 1.4
Marlene Miller
Ranch Hand

Joined: Mar 05, 2003
Posts: 1391
Example 1: interfaces

Example 2: static methods

Example 3: instance methods

Nice formatting, Marlene. Thank you.
Alton Hernandez
Ranch Hand

Joined: May 30, 2003
Posts: 443

Originally posted by Gopal Shah:

No the second code doesn't compile becoz
-> Abc can be converted into Xyz but long cannot be converted into int
-> int can be converted into long but Xyz cannot be converted into Abc

Hi,
I believe you should be looking at the actual type of the reference and parameters used to invoke the method and not the signature of the method.
In the sample program, obj is of type Abc which is assignable to both Xyz and Abc. The parameter 5 is an int which can only be assigned to the parameter l. Therefore, the most specific method is the method declared in Xyz class.
If it is based on the signature alone, then the following code should NOT compile. But it does.

[ September 05, 2003: Message edited by: Alton Hernandez ]
Alton Hernandez
Ranch Hand

Joined: May 30, 2003
Posts: 443
Hi Marlene,
Your Example 3 compiles fine with me.

java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)
Jose Botella
Ranch Hand

Joined: Jul 03, 2001
Posts: 2120
The example compiles but it shouldn't, at least according to JLS 15.12.2.2
___________________________________________________________________________
Given that the compiler is to complain with an error, no actual reference for the objects should be taken into consideration, just the compile type of the classes and parameters.
____________________________________________________________________________

The parameter 5 is an int which can only be assigned to the parameter l

5 is also "method invocation" convertible to long, because "int to long" is a widening conversion.
[ September 05, 2003: Message edited by: Jose Botella ]
[ September 05, 2003: Message edited by: Jose Botella ]

SCJP2. Please Indent your code using UBB Code
Marlene Miller
Ranch Hand

Joined: Mar 05, 2003
Posts: 1391
Alton, I am using 1.4.1_01
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)
Marlene Miller
Ranch Hand

Joined: Mar 05, 2003
Posts: 1391
Here is a bug report about ambiguous methods and interfaces.
http://developer.java.sun.com/developer/bugParade/bugs/4279316.html
Alton Hernandez
Ranch Hand

Joined: May 30, 2003
Posts: 443
Originally posted by Marlene Miller:
Here is a bug report about ambiguous methods and interfaces.
http://developer.java.sun.com/developer/bugParade/bugs/4279316.html

Hi Marlene,
Those two sample codes, A1.java and A2.java, in that bug report compiles fine with me. Don't tell me that they re-introduced that bug because it says there that it had been fixed.
Marlene Miller
Ranch Hand

Joined: Mar 05, 2003
Posts: 1391
What confuses me is that the 1.4.2 fix is inconsistent with the JLS.
Alton Hernandez
Ranch Hand

Joined: May 30, 2003
Posts: 443
Originally posted by Marlene Miller:
What confuses me is that the 1.4.2 fix is inconsistent with the JLS.

Hi all,
I found this amendment to the 2nd edition of the JLS:
It looks like that the phrase class or interface had been dropped from the 3rd paragraph and the word member inserted.


JLS 15.12.2.2
If more than one method declaration is both accessible and applicable to a method invocation, it is necessary to choose one to provide the descriptor for the run-time method dispatch. The Java programming language uses the rule that the most specific method is chosen.
The informal intuition is that one method declaration is more specific than another if any invocation handled by the first method could be passed on to the other one without a compile-time type error.
The precise definition is as follows. Let m be a name and suppose that there are two member methods named m, each having n parameters. Suppose that the types of the parameters of one member method are T1, . . . , Tn; suppose moreover that the types of the parameters of the other method are U1, . . . , Un. Then the first member method is more specific than other if and only if Tj can be converted to Uj by method invocation conversion, for all j from 1 to n. A method is strictly more specific than another if and only if it is both more specific and the signatures of the two methods are not identical.
A method is said to be maximally specific for a method invocation if it is applicable and accessible and there is no other applicable and accessible method that is strictly more specific.
If there is exactly one maximally specific method, then it is in fact the most specific method; it is necessarily more specific than any other method that is applicable and accessible. It is then subjected to some further compile-time checks as described in �15.12.3.
It is possible that no method is the most specific, because there are two or more maximally specific methods. In this case:
If all the maximally specific methods have the same signature, then:
* If one of the maximally specific methods is not declared abstract, it is the most specific method.
* Otherwise, all the maximally specific methods are necessarily declared abstract. The most specific method is chosen arbitrarily among the maximally specific methods. However, the most specific method is considered to throw a checked exception if and only if that exception is declared in the throws clauses of each of the maximally specific methods.
* Otherwise, we say that the method invocation is ambiguous, and a compile-time error occurs.

[ September 06, 2003: Message edited by: Alton Hernandez ]
[ September 06, 2003: Message edited by: Alton Hernandez ]
Jose Botella
Ranch Hand

Joined: Jul 03, 2001
Posts: 2120
Thanks Alton.
Marlene Miller
Ranch Hand

Joined: Mar 05, 2003
Posts: 1391
Thank you very much Alton. I appreciate your research and discovery. I've been thinking the wrong thing all this time.
Gopal Shah
Ranch Hand

Joined: May 17, 2003
Posts: 65
Now its my turn to say "Thanks" to everyone who participated, ofcourse the credit goes to Alton. I must admit that it was as Remington Steele would describe
"NICE WORK DONE"
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Resolving most specific method
 
Similar Threads
Overloading has changed since 1.4.2
reference to method1 is ambiguous ..... java can't decide whic one to call.
About Synchronization concept of static and non static method using Class level lock
calling constructor with null ?
Object assignments