An unexpected failure of the Java compiler. Or is it a failure
of the Java type system?
Java programmers write repetitive code like
HashMap<String, Integer> foo = new HashMap<String, Integer>();
all the time. Those who seek beauty in their code may choose
to use the Google collections library and write instead
HashMap<String, Integer> foo = Maps.newHashMap();
Constructors and static methods interact in very different ways
with generics. If you say new Foo()
you instantiate a raw type, which is quite different from a what
you get by saying new Foo<Bar>().
On the other hand, static methods are the beneficiaries of a little
bit of type inference, as specified by sections
15.12.2.7 and
15.12.2.8
of the Java Language Specification (Third Edition). The actual
rules are complicated (and I haven't read them yet) but the idea
seems to be to use two sources of information:
- the types of the actual arguments
- if the result is "assignment convertible" to some type
T then this type T is used too.
The reason why the Google collections library works is the
second bullet: The compiler uses the type of foo
to figure out how to instantiate the type arguments of
Maps.newHashMap.
OK, that was the background. Now let's see some examples.
Would you expect the following code to compile?
interface A {
static enum Foo { BAR; }
static enum Bar { FOO; }
}
class B<T extends Enum<T>> {
private B() {}
public static <T extends Enum<T>> B<T> get() {
return new B<T>();
}
}
public class C {
public static void main(String[] args) {
B<A.Foo> b = B.get();
}
}
Yes, it works. The Sun Java compiler 1.6.0_13 has no problem in handling
the sort-of recursive bound put on the type.
Now, would you expect the following to work?
interface A {
static enum Foo { BAR; }
static enum Bar { FOO; }
}
class B<T, S> {
private B() {}
public static <T, S> B<T, S> get() {
return new B<T, S>();
}
}
public class C {
public static void main(String[] args) {
B<A.Foo, A.Bar> b = B.get();
}
}
Again, it works flawlessly. After all, why would multiple
type arguments confuse the compiler?
So, you'd expect the following to work too, won't you?
interface A {
static enum Foo { BAR; }
static enum Bar { FOO; }
}
class B<T extends Enum<T>, S extends Enum<S>> {
private B() {}
public static <T extends Enum<T>, S extends Enum<S>> B<T, S> get() {
return new B<T, S>();
}
}
public class C {
public static void main(String[] args) {
B<A.Foo, A.Bar> b = B.get();
}
}
Tough luck, though: It doesn't work. Apparently
"no instance(s) of type variable(s) T,S exist so
that B<T,S> conforms to B<A.Foo,A.Bar>".
I would have thought that T=A.Foo
and S=A.Bar would do the job.
As I said, I haven't read yet the relevant sections in the Java
specification to see if this a problem with the language or a problem
with the compiler. The thing is that the two sections take 10 and a
half screens on my monitor, which signals that I should put aside
maybe one whole day for it, and I don't have one whole day to spend.
My hope is that it is a bug in the compiler, because otherwise I'd
loose some confidence in the language itself. After all, there's
something fishy about a 10-pages algorithm that doesn't end up
trying the obvious solution.
Posts
