Java 8 language spec flaw/bug

[Maurizio Cimadamore]

I believe the spec is correct as is - note that '<=' denotes a 
'type-containment' constraint, not a subtyping constraint. To think 
about type-containment it is sometimes useful think about types in terms 
of 'ranges' over simple hierarchies of types (we can let alone 
interfaces, which only makes everything more complex in this regard). If 
you think about an imaginary line that goes from Object to 'nulltype' - 
you will have the following:

Object
...
Number
...
Integer
...
nulltype

Now, ordinary type (such as Number, Integer) can be thought as 'points' 
in this imaginary line. On the other hand, wildcard type-arguments are 
ranges or intervals on this line. For instance, the wildcard '? extends 
Number' is the interval that goes from Number down to nulltype. 
Type-containment answers a very simple question: is the interval denoted 
by one type contained into the interval denoted by another type?

Now, using the above metaphore, it is easy to see that if you have a 
point-like type in the RHS of a containment-test:

"is a type T contained in Integer?"

The only possible answer is:

"yes, only if T == Integer."

Hence the spec derivation of the equality constraint.

I hope this helps.

Maurizio


On 21/08/14 17:46, Brian Goetz wrote:
> This turns a 'contains' constraint directly into an 'equals' constraint,
> which is precisely what causes the problem. I can see no justification
> for this. It should instead imply a sub-type constraint, that is, it
> should reduce to ‹S |<:| T›. At this point the problem goes away,
> without - as far as I can see - having any negative impact on the
> enhanced type inference that Java 8 provides. Instead of getting two
> conflicting equality constraints for the T in the Foo example above
> (T=String and T=StringBuilder), we would get two subtype constraints
> (String <: T and StringBuilder <: T), which from a theoretical
> perspective is perfectly correct.