commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <>
Subject Re: [collections] VOTE: Collections-java5 direction
Date Mon, 12 Mar 2007 21:09:49 GMT
Bryce L Nordgren wrote:
> Jess Holle <> wrote on 03/12/2007 12:28:34 PM:
>> You can always get the current unchecked behavior with
> Collection<Object>.
> Thing 1:
> ========
> Ummm.  The fact that the above statement is incorrect is precisely why
> Java5 generics syntax is dangerous.  Collection<Object> is not considered a
> supertype of any other typed Collection, and is therefore not
> interchangeable with other typed collections.  (e.g. you can't pass it
> around like you would a Collection)
> To treat the elements of the collection as you always have, one needs
> Collection<Object>, as above.
> To treat the collections themselves as you always have, one needs
> Collection<?>.
> However, if you have a collection which is a supertype of all other
> collections, you cannot add any elements to it because the single legal
> element type for that collection is unknown.
> Thing 2:
> ========
> I don't want the old unchecked behavior.  I want checked behavior,
> commons-collections style.  Commons-collections can handle mixed element
> types, where every element has bounds on its types.  Generics do not even
> contain a way to express "this collection is potentially composed of a
> mixture of elements, but every element is guaranteed to be between {Parent}
> and {Child} in the class hierarchy".  In order to implement this type of
> checked behavior, Java Generics requires that we use the "unchecked"
> syntax.  I guess we should call it "implementation-defined type checking".
> My plea is not intended to start a war over Java generics, but to beg that
> current functionality not be abandonded merely because Java Generics cannot
> adequately describe it.
You can express the bounds of <? extends A super B>, right?  There's 
even a more obscure syntax for expressing something that extends 
multiple classes in cases.

Nothing is perfect, but Java 5 generics seem to strike a good balance.  
Having constraints to express every nuance would kill usability.

You could always use something like Josh Bloch's heterogeneous type-safe 
container pattern if you need something more.

Jess Holle

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message