method reflection does not handle overloading resolution

[jason-s]

This is a major feature missing from both the Java reflection API and the present state of Mirror, IMHO, and is related to issue #44.

If you think, yeah, well, real classes don't have overloaded methods or constructors, look at java.io.File and java.io.FileInputStream.

Use case: you're running an interpreter and you want to allow dynamic method calls at runtime where the object and argument types are not known in advance.

Handling this is not easy and there are quite a few corner cases (at least if you're trying to make overloading resolution match the compile-time overloading resolution in JLS section 15.12 ).

I should be able to help w/ this (as soon as I get permission from our company's legal dept, we've done open-source contributions before so it shouldn't take too long)

[jonasabreu]

Hi jason-s,

issue #44 was related to an easier way to reflect a method when there is only one method with that name defined. You can easily reflect any overloaded method using

Method m = new Mirror().on(clazz).reflect().method("methodName").withArgs(Param1.class, Param2.class);

Does this fix your problem?

[jason-s]

Does this fix your problem?

Nope. That assumes you know the exact classes of the declared method parameters. (e.g. as in Method.getParameterTypes)

All I have is the classes of the actual arguments. (from calling someArgument.getClass())

Just for example, let's say you have

public int compute(Object a0, Object a1) { return 1; }
protected int compute(String a0, Object a1) { return 2; }
public int compute(Object obj, String s) { return 3; }

If your arguments are "hi" and "there", then all three methods are applicable. Only the first and last are accessible. The third method is the most specific method that is applicable and accessible, so it's the one that should be invoked, in order to match the compile-time overload resolution. (all italicized terms in this paragraph are per the JLS)

(see my question on StackOverflow)

[jonasabreu]

Ok. Now I get it.

If you need the method definition, at this moment Mirror can't reflect it, but internally we have code that look for the best match method (but it probably does not follow the compile-time overloading resolution).

That's probably a good point to improve according to the JLS section 15.12. Then we expose this behavior on the DSL.