extend library to include runtime method/constructor resolution?

[jason-s]

I have this problem I'm trying to solve, namely that I'm doing runtime dispatch:

Object dispatch(Object object, String methodname, Class<?> argTypes, Object[] args);

where I need to lookup the matching public method(s) of object and if there's a single "most specific method" (in the JLS 15.12 sense) then I need to invoke it, otherwise I throw an error.

This is turning out to be rather difficult, and I was surprised that Java doesn't give you any help.

(I asked this question on StackOverflow: http://stackoverflow.com/questions/6021109/java-runtime-method-resolution
and one of the answerers referred me to java-classmate.)

It doesn't look like java-classmate presently helps accomplish this.

Would you be willing to include this in the scope of java-classmate? I have a rudimentary approach for resolving methods, it works OK for subtyping + boxing/unboxing, and I'm still stumbling with varargs, but I haven't even touched generics and that seems like the really hairy bit.

[jason-s]

Apache Commons BeanUtils looks like it sort of vaguely does something like what I want, but I have no idea how good it is, I'm skeptical from the javadoc.

What I'd really like is a way to do this:

Object dispatch(Object obj, String methodName, Class<?>[] argTypes, Object[] args) {
    ResolvedType type0 = typeResolver.resolve(obj.getClass());
    ResolvedTypeWithMembers type = memberResolver.resolve(type0, null, null);
    CompatibleMethodFilter cmf = new CompatibleMethodFilter() {
       // I should be able to override somehow to handle primitive type conversion
       // per my application
    }
    ResolvedMethod[] mlist = type.getMostCompatibleMethods(methodName, cmf);
    if (mlist.length == 1)
      return mlist[0].invoke(obj, args);   // exception-handling is not shown here
    else
      // throw appropriate exception
}   

[cowtowncoder]

On Tue, May 17, 2011 at 7:21 AM, jason-s
reply@reply.github.com
wrote:

I have this problem I'm trying to solve, namely that I'm doing runtime dispatch:

   Object dispatch(Object object, String methodname, Class<?> argTypes, Object[] args);

where I need to lookup the matching public method(s) of object and if there's a single "most specific method" (in the JLS 15.12 sense) then I need to invoke it, otherwise I throw an error.

This is turning out to be rather difficult, and I was surprised that Java doesn't give you any help.

(I asked this question on StackOverflow: http://stackoverflow.com/questions/6021109/java-runtime-method-resolution
and one of the answerers referred me to java-classmate.)

Ah cool. I like SO... so much more efficient information dispersal, I
have both found many cool new things, and gotten referral to things I
have done. StackOverflow & Twitter rule. :-)

It doesn't look like java-classmate presently helps accomplish this.

Hmmh. It does match overridden methods, so in that it should help.
That is, given the specific type (runtime class), all methods are
collated to give you the most specific one. This is needed to handle
"annotation inheritance" that classmate implements (which is something
I use with Jackson json processor to implement so-called mix-in
annotations -- or, rather, similar code, Jackson does not yet embed
classmate).

Would you be willing to include this in the scope of java-classmate? I have a rudimentary approach for resolving methods, it works OK for subtyping + boxing/unboxing, and I'm still stumbling with varargs, but I haven't even touched generics and that seems like the really hairy bit.

Generics are not necessarily as problematic as other parts, because
nominal types are type erased. But I'm sure there may be some odd edge
cases.

I am definitely interested in expanding classmate in useful
directions; so if there are aspects of method override process that I
have missed (or that are incorrect or incomplete) let's try to find
out ways to improve things.

-+ Tatu +-

[jason-s]

OK, great -- just to clarify, I'm looking at overload resolution. (Override resolution seems straightforward, but maybe I've missed something)

[cowtowncoder]

Ah... so just methods that have same name but differing arguments? This is not currently supported, but might be easy to add. Just need to figure out what would be best way to expose it via interface, since it is sort of alternative view to grouping of things