Java 8 language spec flaw/bug

[Davin McCall]

>
>>
>> In this case the answer is
>>
>> "yes, if T is Integer, or a wildcard '? extends (some supertype of 
>> Integer)'.
> No - only Integer, as a 'wildcard' won't be a 'type' - wildcards are 
> said to be type-arguments in the JLS lingo. They are not types.

Yes, but:

> Which means the paragraph you quoted only speaks about S and T being 
> proper types such as String, Integer.

No! the paragraph I quoted was:

    ---begin---
    A constraint formula of the form ‹S |<=| T›, where S and T are type
    arguments (§4.5.1
    <http://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.5.1>),
    is reduced as follows:

    If T is a type:

      *

        If S is a type, the constraint reduces to ‹S = T›.

    ---end---


My assumption is that in:

    static  <T>  T foo(Class<T>  clazz) { ... }
    static  <U>  U ternary(boolean  cond,  U a,  U b) {...}
    foo(ternary(true,  String.class,  StringBuilder.class));


The type arguments are those of Class - i.e. String and StringBuilder 
(from Class<String> and Class<StringBuilder>, being the types of 
String.class and StringBuilder.class respectively). These are used to 
impose constraints on the type variable T (for the foo function). So the 
constraints are: ‹String |<=| T› and ‹StringBuilder |<=| T›. Are you 
saying that the paragraph I quoted does not apply, since 'T' is a type 
variable and not a proper type? In that case should I apply instead:

    ---begin---
    A constraint formula of the form ‹S |<:| T› is reduced as follows:
          ... (some snipped) ...

      *

        Otherwise, if T is an inference variable, α, the constraint
        reduces to the bound S |<:| α.

    ---end---

If I apply this, the resolution succeeds, I think. Why then does 
compilation fail?


>>
>> This derivation of an equality constraint is too strong, as I have 
>> shown; containment is not equality.  I do however take your point 
>> about changing the contains constraint to a sub-type constraint being 
>> an incorrect solution. I suspect now that a full solution would 
>> require significant changes to the current wording of the spec.
> Why is it 'too strong' ?

Because it requires that a type variable be resolved to a specific, 
proper type, rather than allowing it to be a capture of a range of 
types. (Unless I was wrong and this paragraph does not apply at all for 
the example I am concerned with).

If it is applied only to proper types which are not type variables, then 
it is not too strong. The problem occurs when it is applied to type 
variables. I hope this makes sense,

Davin