jakarta-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
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
this.

Stephen

----- Original Message -----
From: "Chris Lambrou" <mail@chrislambrou.com>
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


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


Mime
View raw message