Community
Participate
Working Groups
When compiling the following piece of code > Test.java >>> import java.util.*; public class Test { public static <A> Set<A> method(List<? super A> list) { return new HashSet<A>(); } public static void main(String[] args) { ArrayList<Number> l = new ArrayList<Number>(); Set<Integer> s1 = method(l); Set<Integer> s2 = (Set<Integer>)method(l); } } < Test.java <<< 3.2M5a rejects the second assignement because of an invalid cast. I know that javac (1.6.0-beta2-b73) produces the same compile time error (with a different justification), but is this the correct behaviour. What's the difference between the implicite and the explicite cast or rather should there be a difference?
This behavior is mandated by the spec, though I don't like it either. Basically, after inferring using type arguments, it yields the constraint: A <: Number (both invocation of #method(l) are reaching this point using JLS 15.12.2.7). When resolving constraints, only '=' and '>:' constraints are considered, i.e. none here. Thus, and this is where both invocations differ, variable bounds (none here) and return type expectation are considered (JLS 15.12.2.8). The latter is different in between the 2 invocations, as the first is subject to assignment conversion, whereas the second is subject to cast conversion. Only assignment conversion are considered to create type expectation by the spec. I believe this is very misleading, but unfortunately this is enforced by the language spec which we do not own. You should complain against the owner of the language, there is a spec component there.
In latter case, javac seems to infer Object for A (when complaining about type mismatch), but I think this is wrong due to the constraint: A <: Number. Added GenericTypeTest#test944
