The Java Language Specification, Third Edition

15.12.2 Compile-Time Step 2: Determine Method Signature EXPRESSIONS
458
hold true. It follows that V[] >> U[]. Since array subtyping is covariant, it must be the case
that V >> U.
❖ If F has the form G, where U is a type expression
that involves Tj, then:
DISCUSSION
✣ If A is an instance of a non-generic type, then no constraint is implied
on Tj. In this case (once again restricting the analysis to the unary case), we have the constraint
A >> F = G. A must be a supertype of the generic type G. However, since A is not a
parameterized type, it cannot depend upon the type argument U in any way. It is a supertype
of G for every X that is a valid type argument to G. No meaningful constraint on U
can be derived from A.
DISCUSSION
✣ If A is an invocation of a generic type declaration H, where H is either G
or superclass or superinterface of G, then:
✦ If H ≠
G,
then let S1, ..., Sn be the formal type parameters of G, and let
H be the unique invocation of H that is a supertype of
G, and let V = H[Sk =U]. Then, if V:>F
this algorithm is applied recursively to the constraint A >> V.
DRAFT
Our goal here is to simplify the relationship between A and F. We aim to recursively invoke
the algorithm on a simpler case, where the actual type argument is known to be an invocation
of the same generic type declaration as the formal.
Let’s consider the case where both H and G have only a single type argument. Since
we have the constraint A = H >> F = G, where H is distinct from G, it must be the
case that H is some proper superclass or superinterface of G. There must be a (non-wildcard)
invocation of H that is a supertype of F = G. Call this invocation V.
If we replace F by V in the constraint, we will have accomplished the goal of relating
two invocations of the same generic (as it happens, H).
How do we compute V? The declaration of G must introduce a formal type parameter
S, and there must be some (non-wildcard) invocation of H, H, that is a supertype of