When generics were originally introduced to Java, the type inference algorithm was capable of inferring the type arguments to a generic method invocation in more contexts than are supported today. See http://lampwww.epfl.ch/~odersky/ftp/local-ti.ps for a description of the issue and the techniques used in the compiler. Late in the process of preparing for the JDK5 release, we removed some of those capabilities due to concerns about how well the JLS specification and implementation matched. There is enough time between now and the likely release of JDK7 to address the specification issues and add compiler support.
Here is the issue: given a method declaration
static <T> List<T> newList() { return new ArrayList<T>(); }
and an expression appearing somewhere in the code
newList()
what is the type of this subexpression? This question is hard to
answer in the absence of context. On the right hand side of an
assignment to a variable of type List<String>, one
would expect the type to be List<String>. But what
if the expression is an argument to in invocation of a (possibly
overloaded) method? Or what if it appears before the "dot" operator in
an invocation of a member method? The jsr14 prototype compiler handled
these cases just fine, using the concept of a "quantified
type". Internally, javac treated this expression as being of type
"for all T, List<T>."
But the approach used in the draft JLS specification avoided these quantified types, instead using general rules that mentioned only types that appeared in the language spec. My concern was that because javac and the specification used completely different approaches, it would be very difficult to validate that they did the same thing. Absent that confidence, we thought it better to delay support for this aspect of generics to an update release, or possibly the next major release. Unfortunately, reality conspired to prevent that from happening.
But it isn't too late.