You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2004/09/17 20:17:45 UTC
Port commons-collections to generics under 1.5
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" <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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Port commons-collections to generics under 1.5
Posted by Michael Heuer <he...@acm.org>.
Hello Chris,
I feel it would be best to implement collections + generics as a project
in the commonds sandbox. That way we get cvs, bugzilla, gump,
ibiblio/maven mirror, etc. support and lots of interested eyeballs on the
commons mailing list. But we would need an apache committer.
Without an apache committer, we would probably have to go with a
SourceForge project and then try to migrate it back into commons at some
later point. Would that have to go through the Incubator?
For what it's worth, I also want to point out the Java Generic Algorithms
project (LGPL), which does not have collections implementations, but does
have functors well covered, see
> http://jga.sourceforge.net
michael
On Mon, 27 Sep 2004, Chris Lambrou wrote:
> Thanks for offering to help, Michael. Stephen suggested we start by
> converting the collections interfaces to use generics, and cleaning up a
> few issues relating to backwards compatibility on the way. I've done
> this, and in the first instance the interfaces could really do with some
> proper scrutiny before anyone goes too far with converting the
> implementations. As neither of us are committers, and it's unfair and
> unworkable to rely on Stephen to act as a CVS proxy, we need to sort out
> an alternative version control system. I'm open to any suggestions.
>
> Since generifying the Transformer, Predicate, Closure and Factory
> interfaces was straightforward and doesn't really warrant any additional
> scrutiny, I've already gone ahead and converted the functors and
> comparators sub-packages, complete with successful unit tests. I'll
> send all of this to you (Michael) in a separate email. If anyone else
> wants to have a gander at it all, just drop me an email - again,
> suggestions for a VCS solution are welcomed.
>
> Chris
>
>
>
>
> Michael Heuer wrote:
>
> > 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
> >>
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: Port commons-collections to generics under 1.5
Posted by Chris Lambrou <ma...@chrislambrou.com>.
Thanks for offering to help, Michael. Stephen suggested we start by
converting the collections interfaces to use generics, and cleaning up a
few issues relating to backwards compatibility on the way. I've done
this, and in the first instance the interfaces could really do with some
proper scrutiny before anyone goes too far with converting the
implementations. As neither of us are committers, and it's unfair and
unworkable to rely on Stephen to act as a CVS proxy, we need to sort out
an alternative version control system. I'm open to any suggestions.
Since generifying the Transformer, Predicate, Closure and Factory
interfaces was straightforward and doesn't really warrant any additional
scrutiny, I've already gone ahead and converted the functors and
comparators sub-packages, complete with successful unit tests. I'll
send all of this to you (Michael) in a separate email. If anyone else
wants to have a gander at it all, just drop me an email - again,
suggestions for a VCS solution are welcomed.
Chris
Michael Heuer wrote:
> 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
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: CVS access configuration problems
Posted by Chris Lambrou <ma...@chrislambrou.com>.
Martin,
As I said, I haven't used CVS much and wasn't aware of the distinction
between modules and repositories. It also didn't seem obvious to me
that the WinCVS gui allows one to type in any repository name, rather
than having to select one of the modules. Anyhow, it's all worked a
treat, so many thanks.
Chris
Martin Cooper wrote:
>By and large, we don't use the CVS "modules" feature, which is why you
>see so few. You just need to use the repository name instead. So, for
>Commons, you would check out jakarta-commons and / or
>jakarta-commons-sandbox.
>
>--
>Martin Cooper
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: CVS access configuration problems
Posted by Martin Cooper <mf...@gmail.com>.
By and large, we don't use the CVS "modules" feature, which is why you
see so few. You just need to use the repository name instead. So, for
Commons, you would check out jakarta-commons and / or
jakarta-commons-sandbox.
--
Martin Cooper
On Sat, 25 Sep 2004 09:17:53 +0100, Chris Lambrou <ma...@chrislambrou.com> wrote:
> Hi,
>
> I'm having trouble setting up CVS access to the Jakarta modules. I'm
> trying to configure WinCVS as my CVS client, and I've followed the
> instructions shown at http://jakarta.apache.org/site/cvsindex.html. All
> appears to go well - the client successfully connects to the CVS
> repository using the suggested connection command
>
> cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic login
>
> but when I try to search for modules to check out, I can only see the
> following:
>
> apache-1.3
> apache-1.3-sourceonly
> apachetest-alias
> htdocs-1.3
> httpd-docs-1.3
> httpd-docs-2.0
> modperl-2.0
> modperl-docs-alias
> world
>
> I was hoping to see a lot of Jakarta modules in there, but there's
> nothing related to Jakarta in the list. Am I doing something stupid
> here? Is the Jakarta stuff actually hosted on cvs.apache.org or do I
> need to connect to a different host (e.g. cvs.jakarta.apache.org)? A
> little help in this matter would be greatly appreciated as I'm
> relatively new to the world of CVS.
>
> 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
CVS access configuration problems
Posted by Chris Lambrou <ma...@chrislambrou.com>.
Hi,
I'm having trouble setting up CVS access to the Jakarta modules. I'm
trying to configure WinCVS as my CVS client, and I've followed the
instructions shown at http://jakarta.apache.org/site/cvsindex.html. All
appears to go well - the client successfully connects to the CVS
repository using the suggested connection command
cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic login
but when I try to search for modules to check out, I can only see the
following:
apache-1.3
apache-1.3-sourceonly
apachetest-alias
htdocs-1.3
httpd-docs-1.3
httpd-docs-2.0
modperl-2.0
modperl-docs-alias
world
I was hoping to see a lot of Jakarta modules in there, but there's
nothing related to Jakarta in the list. Am I doing something stupid
here? Is the Jakarta stuff actually hosted on cvs.apache.org or do I
need to connect to a different host (e.g. cvs.jakarta.apache.org)? A
little help in this matter would be greatly appreciated as I'm
relatively new to the world of CVS.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Port commons-collections to generics under 1.5
Posted by Michael Heuer <he...@acm.org>.
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" <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
> >
>
>
> ---------------------------------------------------------------------
> 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