Reference implementation

Maurizio Cimadamore Maurizio.Cimadamore at Sun.COM
Thu Oct 29 02:48:32 PDT 2009

Neal Gafter wrote:
> On Wed, Oct 28, 2009 at 1:41 PM, Jonathan Gibbons
> <Jonathan.Gibbons at>wrote:
>>  In the short term, we think that the current ("simple") approach is the
>> way to go. Long term, we think we will need something like the
>> "full-complex" approach that Maurizio has described. That will address the
>> need for argument inference. However, we do not have the resources to fully
>> investigate that solution at this point.
> I don't believe that the full-complex approach is both implementable and
> upward compatible with the simple approach.  However, it hasn't been
> specified in any detail, so it isn't possible for a demonstration to be made
> either way.  
Neal, the complex-full approach is essentially your approach plus some 
magic to make the following work:

Foo<Object> = new Foo<>(1);

That is, a complex approach that takes into account the expected return 
type in order not to infer a type which is too specific. Such an 
approach would be compatible with the currently implemented simple 
approach (in fact, ANY other approach that takes into consideration the 
expected return type would be compatible with the simple approach).

I see your point about choosing between usability and language 
evolution. To be honest this seems quite a small price to pay compared 
to other choices that have been made for Java w.r.t. to language 
evolution. To name 3:

1) support for generic cast w/o reification and raw types --> have made 
reification nearly impossible
2) wildcards --> despite their usefulness when writing library methods 
they have made the type-system undecidable (well we don't have a full 
proof yet, but certainly we have bugs)
3) addiction of synthetic types (captured/intersection types) for better 
type-inference --> lead to infinite types and, again, makes it really 
hard to discuss seriously about reification

In other words I don't think that  the current implementation of diamond 
should be blamed for putting Java into the corner. As a side-issue 
consider also that the complex approach, and any other inference 
approach taking into account actual argument types, has the ''drawback'' 
of inferring captured types as possible instantiation for a generic 
type. E.g.

void m(List<?> ls) {
   Foo<?> f = new Foo<>(ls.head); //inferred as Foo<#1>, where #1 
extends Object

Again I don't think that is is particularly good in term of language 
evolution - what does it mean to create an instance of a generic type 
parameterized with a captured type? What should the runtime semantics of 
Foo<#1> be (assuming you have reification) ?

The simple approach is not corner case-free - there are circumstances in 
which simple infers an intersection type, e.g. if the class 
type-variable has multiple bounds - but it is definitively better than 
having to support intersection types AND captured types at the same type.


> I'm afraid that the currently integrated approach really is
> painting us into a corner.  The "complex" approach is more clearly upward
> compatible.  If there are insufficient resources to fully investigate, the
> conservative solution would be to implement the "complex" approach (or none
> at all).
> I find it remarkable that multi-catch was rejected from Coin for veering too
> near the type system (even though it doesn't effect the type system), while
> at the same time decisions about generic type inference are being included
> in Coin even though we lack the resources to fully investigate their
> long-term impact.
> -Neal

More information about the coin-dev mailing list