Name: krT82822			Date: 11/03/99


java version "1.2.2"
Classic VM (build JDK-1.2.2-W, native threads, symcjit)

In its current form, the getMethod(String, Class[]) imposes a high degree
of precision in the Class argument it receives.  Specifically, if a
valid subclass of the 'proper' argument class is passed, a NoSuchMethodException
is thrown at compile-time.

The following demonstrates the principle:

import java.lang.reflect.*;

class Super { }

class Sub extends Super { }

public class Foo {

	public void bar(Super s) { System.out.println("Test"); }

	public static void main(String[] args) throws Throwable
		{
		 Sub sub = new Sub();
		 // This works as expected and advertised.
		 java.lang.reflect.Method method = Foo.class.getMethod("bar",
new Class[] { Super.class } );
		 
		 // The following throws a NoSuchMethodException, though sub is
an instance of a valid Super subclass
		 java.lang.reflect.Method method = Foo.class.getMethod("bar",
new Class[] { sub.getClass() } );
		 
		 // RFE: Allow for 'lazy' resolution to the most specific
applicable method,
		 // governed by the same rules that apply to the resolution of
multiple applicable
		 // methods at compile-time.
		 
		 method.invoke(new Foo(), new Object[] { sub });
		}
}

It would be of some utility if, when the Class passed into the getMethod method
is not of the precise type, its superclasses were queried and the most specific
valid method returned (following the same rules applied to overloaded methods
at compile time) if found.
(Review ID: 97431) 
======================================================================

Roger.Rawlinson@Ireland 2000-03-07

I've got a Licencee who is also asking for this functionality. 

I would also point out that the evaluation says that when a method is called
it's the job of the compiler to search for any sub classes that match. This is
true ONLY if a method has been declaired as final. For most cases I'd expect the
VM to have to perform the search. This means that the code to search for
subclasses in the parameter list is already in the VM, and consequently
implementing a new API should not effect the memory footprint too much.

I've attached a small test case which shows this.

-----
The same problem occurs with Class.getMethod, Class.getDeclaredMethod,
Class.getConstructor, and Class.getDeclaredConstructor.  Bug 4651775 contains a
request to specify the meaning of "match" in the javadoc for these methods.

-- iag@sfbay 2002-03-12