commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Lambrou <>
Subject [collections] Port to generics under 1.5
Date Tue, 14 Sep 2004 20:27:02 GMT
I thought I'd make a start on converting commons-collections to use 
generics under the JDK 1.5.  Before I go too far, I'd like to hear 
peoples comments on the subject.  In particular, I'd like to know what 
people have to say about the following issues.


 From previous discussions on this subject, the general concensus seems 
to be that we should start a new project, [collections15], rather than 
trying to shoehorn generics into [collections], which is required to 
maintain backwards compatibility with older versions of the JDK.  It is 
clear, however, that there would be great similarities between the 
codebases of [collections] and [collections15]. Should we aim to 
ultimately develop the two in parallel, just try to keep the public APIs 
similar (they can't be kept identical - see MultiMap below) or allow the 
two projects to drift off in different directions over time?  
Furthermore, if the codebases do remain very similar, what's the best 
way to handle the tracking of bugs which affect both projects?


Most of the interfaces defined in [collections] can be trivially adapted 
to generics. The only exception is MultiMap.  MultiMap violates the Map 
interface, as after calling put(key, value) on a map, get(key) doesn't 
return value, but a Collection containing the value.  This works fine 
for the current Map interface, since Object get(Object key) can 
legitimately return a Collection instance rather than the original 
Object. It's not possible to continue with the current behaviour with 
generics. The map interface's get method now has the signature V get(K 
key), and so we simply cannot return a collection of type 
Collection<V>.  It seems to me that we'll have to settle for a 
Collection<V> getValues(K key) method, but the question is, what happens 
to V get(K key)?  I can think of three obvious behaviours:

1. V get(K key) should throw an UnsupportedOperationException.

2. V get(K key) returns one of the values that is mapped to the 
specified key. The choice of exactly which value is left to the 

3. V get(K key) should return the latest value to be mapped against the 
specified key.

I'm not keen on either of the first two options, as they both violate 
the Map interface. The first because Map doesn't specify that V get(K 
key) is an optional operation, and the second because it doesn't 
guarantee that get(key) will return value after put(key, value) has been 
called.  The third option looks good to me, but it would pretty much 
require that the values for each key must be stored in a list, so that V 
get(K key) always returns the latest value mapped, even taking into 
account any calls to V remove(K key, Object item).

Also, on a more practical level, since I'm new to the Apache development 
scene, I obviously can't setup a project or commit any code. What's the 
best way to get things started?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message