Why doesn't this program compile?

Question

Compiling this program:
  public class Foo<T> {
    private final Class<T> type;
    public Foo(Class<T> type) {
        this.type = type;
    public T cast(Object obj) {
        return this.type.cast(obj);
    public void handle(T obj) {
    static void apply(Foo<?> foo, Object obj) {
        foo.handle(foo.cast(obj));
  }gives this error:
    Foo.java:12: handle(capture#31 of ?) in Foo<capture#31 of ?>
      cannot be applied to (java.lang.Object)
    foo.handle(foo.cast(obj));
    ^But this seems bogus. Obviously the result of foo.cast(obj) (generic type T) should be compatible with handle(), which takes a T.
Am I missing something or is this a compiler bug (or limitation)?
This is on openSuSE 11.1:
    $ javac -version
    javac 1.6.0_0
    $ rpm -qf /usr/lib/jvm/java-1.6.0-openjdk/bin/javac
    java-1_6_0-openjdk-devel-1.6_b16-0.1.3Thanks for any insights.

Answer 1

endasil wrote:
alc wrote:
Thank you, this I understand... though it's a little disappointing the compiler can't make the simple inference required. I guess that would require data flow analysis.Which is easier said than done, and sometimes impossible.
Imagine you changed Foo thusly:
static Foo<?> foo = new Foo<String>(String.class);
static void apply(Object obj) {
foo.handle(foo.cast(obj));
}And then used it like this:
public class GT7 {
public static void main(String[] args) {
new Thread(new Runnable() {
public void run() {
Foo.foo = new Foo<Integer>(Integer.class);
}).start();
Foo.apply("Hello!");
}How's the compiler supposed to figure that one out?Yes, if there is a race condition the compiler obviously can't assume "foo" won't change. But that's not the case in the original program.. foo is a local variable. A compiler could (with sufficient work) prove this to itself. This is not one of those an impossible Turing-complete scenarios like you sometimes see with "uninitialized variable" errors where the variable actually is always initialized.
I'm not saying that it's necessarily worth the effort to implement this in the compiler. My only point is that this was strictly a language/compiler design choice -- and a reasonable one. But there's also nothing wrong with the "intent" of the program, even if the compiler doesn't "get it".