I'd expect the following to compile:

given the generic method

<T> T getOption();

the subsequent call will fail to compile with javac

int i = getOption();

At first I regarded this as a javac bug, but after a deeper look at the spec, it seems that no autoboxing should be exploited here:

accordingly to 15.12.2.8, a constraint of the kind int >> T should be derived. However it seems that rules in 15.12.2.7 cannot derive the constraint Integer >> T starting from this initial constraint. So we cannot derive anything useful from this constraint. Maybe 15.12.2.8 should be changed in order replaced the primitive type with the boxed type in case the return type is primitive.

Here's a test-case:

public class X {
    public static <T> T getValue(T t1, T t2) {
        return t1;
    }

    public void testGenerics(Comparable<String> s) {
        int i = getValue(0, s);
    }
}
Posted Date : 2008-12-15 13:36:27.0

N/A

JLS3 integrated boxing and unboxing conversion into overload resolution at a high level (the 'applicable by method invocation conversion' step), and did not push them all the way down into the inference algorithm per se. The fix is:

"Then, a set of initial constraints consisting of:

- the constraint box(S) >> R', provided R is not void;
  ***(where box(S) is S if S is a reference type,
      and   box(S) is the result of applying boxing conversion (5.1.7) to S if S is a primitive type)***
  and
- additional constraints ..."
Posted Date : 2008-12-17 17:01:18.0