[collections] Port to generics under 1.5

[Chris Lambrou <ma...@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

Re: [collections] Port to generics under 1.5

[Stephen Colebourne <sc...@btopenworld.com>]

From: "Chris Lambrou" <ma...@chrislambrou.com>
>  From previous discussions on this subject, the general concensus seems
> to be that we should start a new project, [collections15],
+1

> 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?
I would hope they would be similar in terms of API, however there will be
differences. Errors in [collections] should not be replicated, nor for
example should the Buffer API, as it is replaced by Queue in JDK1.5.

> Most of the interfaces defined in [collections] can be trivially adapted
> to generics. The only exception is MultiMap.
...
> 3. V get(K key) should return the latest value to be mapped against the
> specified key.
This is the nicest option of those presented. You may also want to search
the archives/bugzilla, as there have been requests to add methods to
MultiMap, which could be done at this point.

> 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?
Firstly, thanks for offering to help. Do you have other OSS experience to
build on here?

My difficulty is that I can't realistically commit my time to watch every
commit as I'm stretched elsewhere. That said, I will try and provide advice
when I can.

I believe that there may be other apache committers willing to help with
this task. Hopefully they will reply here, otherwise we may have to ping the
jakarta-general list.

One possible solution may be to develop the code at sourceforge, and then
bring it back here, but that does feel rather stupid. Another solution is to
vote you in as a committer, but I think we would want a current committer
willing to take a role alongside you to help review code and so on. Lets see
who else replies....

Stephen



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