commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <scolebou...@btopenworld.com>
Subject Re: [collections] Generifying Collections
Date Wed, 25 Oct 2006 16:12:27 GMT
From: Niall Pemberton <niall.pemberton@gmail.com>
> From a simplistic user perspective seems to me that the compatibility
> achieved by the JDK is successful. I don't understand the intricacies
> required to generify a library, but if we could do the same wouldn't
> this be the best solution from a user perspective?
> 
> Perhaps you could expand on what the issues are with the JDK approach
> and why they're not desirable in Commons Collections - when I look at
> the differences for example between the generified and non-generified
> versions of java.util.List, I don't see the mess you describe.

The problem is erasure. The JDK wipes all knowledge of the type that you connect to the collection.
Thus

List<String> list = new ArrayList();
if (list instanceof List<Integer>) {
}

fails to compile as the String type is erased.

In order to preserve backwards compatability, Sun had to go to extreme lengths to ensure that
the erased type of each generics element corresponds to the previous type of the method. Consider
the max method on Collections:

public static <T extends Object & Comparable<? super T>> T max(Collection<?
extends T> coll)

Where because Object comes before Comparable in the list of bound types, its Object that the
method signature gets erased to. Now thats pretty nasty.


For [collections], there are cases worse than this, such as MultiMap, where the sf projects
have demonstrated that it is not possible to generify the class without breaking backwards
compatability, typically because our interface isn't a true implementation of the original
interface.


Beyond this, there are some classes (like TypedList that we don't even want to port as they'd
be pointless), plus my desire to create a smaller jar file (time depending), there is ample
reason to not worry excessively about backwards compatability. We shoud target about 90% backwards
compatible, with the rest being fixing API flaws and issues we have now.

A simple port may appeal conceptually, but its not really viable at all.

Stephen





---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message