Proposal: Simplified syntax for dealing with parameterized types.

Joseph D. Darcy Joe.Darcy at Sun.COM
Mon Mar 23 18:16:48 PDT 2009

james lowden wrote:
> Yeah, the "Map<String, String> map = new HashMap<>();" is a lot simpler (and something I've wanted. . .); I'd actually like to see both that and the ideas I've suggested implemented. . .

Yes, Jeremy sent around a proposal for that in the first days of the 
call for proposals; a revised is in the works.

> I may be attempting to kill multiple birds with one stone here; part of it is removing repitition from code, which the previously-floated proposal addresses.  The other thing I'm trying to do is provide an "easier" way to use parameterized types in a type-safe fashion, without (unfortunately, in my mind) providing some kind of reification.

> I'm thinking of two different kinds of "type safety".  One is making it harder to "break" the parameterized type (by, for example, setting a HashMap<String,String> reference to a plain HashMap); the subclassing provides this.

The concerns you have with converting to/from rawtypes could be handled 
with either new lint flags to the compiler or annotation processors to 
reject such conversions.

> The other feature I'm looking for is some kind of differentiation-of-intent;

Declaring a new type strikes me as a fine way to indicate 
differentiation of intent :-)

Therefore, combined with the shorter declaration syntax and the ability 
to cause compilation errors for raw types without change the language, I 
don't see a strong motivation for this change.

>  Java already has this in the case of enums (i.e., any given four-value enum is in some sense "equivalent" to any other, as they are both internally represented by one of four integer values, but you can't interconvert);

In their serial form, enums are represented by their names, not their 
ordinal values.  Also, enums can and do define type-specific behavior.  
Therefore, all enums with the same number of constants are not 
semantically equivalent.


More information about the coin-dev mailing list