commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Heuer <heue...@acm.org>
Subject Re: Port commons-collections to generics under 1.5
Date Fri, 24 Sep 2004 20:17:34 GMT

For what it's worth, I'd be willing to help in this effort, but I am not
an committer.  In fact I've started on a couple of different occasions to
do this myself, but I stop short -- [collections] is a lot of code.  :(

   michael


On Fri, 17 Sep 2004, Stephen Colebourne wrote:

> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
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