non-wildcard parameterization

[Dan Smith]

You're right, this is a javac bug.

The motivation of the spec is to carve this space out for future improvement, if necessary: if it turns out some common patterns could use some better analysis (yours is a good example), we can come back and design something to address that.  But the general problem doesn't have a good solution, so we have to draw a line somewhere.

—Dan

On Feb 6, 2014, at 9:44 AM, Stephan Herrmann <stephan.herrmann at berlin.de> wrote:

> I don't understand the javac behavior for the following example:
> 
> 
> interface I<T, S extends X<T>> {
>    T foo(S p);
> }
> 
> public class X<T>  {
>    public void bar() {
>    	I<Object, ? extends X<Object>> f = (p) -> p;
>    }
> }
> 
> javac accepts, but I don't see how the non-wildcard parameterization of I
> can be determined for this case.
> 
> I believe compilation should fail during this sentence from 9.8:
> "If Ai is a wildcard, and the corresponding type parameter bound, Bi,
> mentions one of P1...Pn, then Ti is undefined and there is no function type."
> 
> From the LHS of the assignment:
> F<A1...An> = I<Object,? extends X<Object>>
> A1 = Object
> A2 = ? extends X<Object>
> 
> From the declaration of I:
> P1 = T
> P2 = S extends X<T>
> B1 = n/a
> B2 = X<T>
> 
> A2 (? extends X<Object>) is a wildcard, and the corresponding bound, B2 (X<T>),
> mentions P1 (T), hence Ti is undefined and there is no function type.
> 
> is my interpretation of the spec correct?
> 
> thanks,
> Stephan