commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Port commons-collections to generics under 1.5
Date Fri, 17 Sep 2004 18:17:45 GMT
Fowarding to jakarta general list from commons.

Are there any apache committers willing to help out on porting
commons-collections to JDK1.5?? I'm overloaded ATM, so can't really help.
Whats needed is an existing committer willing to make commits and work on


----- Original Message -----
From: "Chris Lambrou" <>
> 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.
> Project
>  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?
> MultiMap
> 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
> implementation.
> 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?
> Chris
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message