#97 Erroneous ReflectionSupport.canAutoBoxFromActualToFormal

[Garmann]

The static method ReflectionSupport.canAutoBoxFromActualToFormal delivers wrong results. As a consequence the method public static <T> T create(Class<T> returnType, Object ... params) fails.

Example: class with two constructors:
public class X {
public X(int i) { ... }
public X(double d) { ... }
}

ReflectionSupport.create(X.class, 5.2);

The create call internally searches for a matching constructor. The method public static Constructor<?> getMatchingConstructor(Class<?> c, Class<?> ... params) may deliver the first constructor, because canAutoBoxFromActualToFormal(Double.class, int.class) returns true. The first constructor receives a newInstance call, which fails (java.lang.IllegalArgumentException: argument type mismatch).

Suggested fix:
public static boolean canAutoBoxFromActualToFormal(
Class<?> actual, Class<?> formal)
{
return
( ( formal.equals(byte.class)
&& actual.equals(Byte.class) )
||( formal.equals(short.class)
&& Short.class.isAssignableFrom(actual) )
||( formal.equals(int.class)
&& Integer.class.isAssignableFrom(actual) )
||( formal.equals(long.class)
&& Long.class.isAssignableFrom(actual) )
||( formal.equals(float.class)
&& Float.class.isAssignableFrom(actual) )
||( formal.equals(double.class)
&& Double.class.isAssignableFrom(actual) )
||( formal.equals(boolean.class)
&& actual.equals(Boolean.class) )
||( formal.equals(char.class)
&& actual.equals(Character.class) ));
}

[Stephen H. Edwards]

This is definitely a bug. We're in the process of rewriting the reflection infrastructure to correctly implement proper overload resolution rules, but it will be a while before the fix is ready.

However, we do plan to make it available through our transparent support for reflection (i.e., write reference tests completely normally, but the plug-in will dynamically transform them through bytecode rewriting to use reflection automatically). We're hoping that will be ready for fall.

[Stephen H. Edwards]

Now fixed in HEAD.

The problem was much deeper and more complicated than it at first appeared. Although there definitely was a problem with incorrect handling of numeric conversions and boxing/unboxing, there was also a significant issue with overload resolution--which just wasn't implemented (by design).

The fix that I just committed includes a complete rewrite of the method/constructor search procedure. Argument compatibility is now tested using the exact JLS rules for method invocation conversions, and so it correctly handles both boxing/unboxing and widening conversions for primitives and references using the same rules as the compiler. However, another big addition is that the search procedure now also follows the JLS rules for overload resolution, giving true overloading behaviors (except for generics--overload resolution for generic parameters is not implemented) in the way you would expect.

This update fixes the example cited in this bug report, as well as many other situations where the behavior was incorrect (or inconsistent) before.

The update will be included with the next downloadable version of student.jar and the next published version of the JavaTddPlugin.