[lang] MethodUtils Inner Class Accessibility

[Arun Thomas <Ar...@solidusnetworks.com>]

I wrote some additional tests for MethodUtils which fail given the current implementation.  Except I'm unsure whether this is because I'm testing for something that I shouldn't expect, or because the behaviour of the functions are wrong.  I'll attach patches for the test cases (testGetAccessibleMethodInaccessibleInnerClass & testInvokeInaccessibleInnerClass) which show this issue, but I detail below:

Question....

Suppose a package protected class contains a public inner class with public methods.  It is impossible, in code outside the package, to invoke methods declared on this inner class through direct java code (without subclassing), simply because it is not possible to type an object as having the type of the inner class in order to access the methods of the class at compile time.  Should it be possible to invoke the same methods by reflection?  

Example:

------------------------------------------------------------------
package x;

Class OuterClass {
  public static Class InnerClass {
    public Object innerClassMethod(Object o) {
      return o;
    }
  }
}

public Class Factory {
  public static Object getInnerClassObject() {
    return new OuterClass.InnerClass();
  }
}
------------------------------------------------------------------
package y;

public class CallingClass {
  public static void main(String[] args) {
    Object innerClassObject = Factory.getInnerClassObject();
    Object arg = new Object();

    // Impossible - because Outerclass is not accessible 
    // ((OuterClass.InnerClass) innerClassObject).innerClassMethod(arg);

    // Should the following be possible without raising an exception?
    // Currently, this is possible....
    try {
      MethodUtils.invokeMethod(
        innerClassObject,
        "innerClassMethod",
        arg);
    } catch (Throwable t) {
       // Should I end up here or not?  
    }
  }
}
------------------------------------------------------------------

Thanks, 
-AMT

P.S. The attached patche also breaks down a large test in MethodUtils into multiple small tests, but that is besides the point of this email.