Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4287725

(reflect) Allow subclasses of stated argument types in Class.getMethod()

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Unresolved
    • Icon: P4 P4
    • None
    • 1.2.2, 1.3.0
    • core-libs
    • Fix Understood
    • generic, x86
    • generic, windows_98, windows_nt



      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

            Unassigned Unassigned
            kryansunw Kevin Ryan (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Imported:
              Indexed: