Commons-Collections enhanced with Java Generics Support

[John Watkinson <co...@spamgourmet.com>]

Dear Jakarta Commons developers,

We are pleased to announce that we have enhanced the Commons-Collections 
with Java 1.5 generics support! We have the results hosted on SourceForge:

http://collections.sf.net

We have done our utmost to maintain the exact same functionality as 
Collections 3.1. We have eliminated all deprecated classes that were 
scheduled for removal in 4.0. Furthermore, we have deprecated all the 
TypedXXX classes since they are made obsolete by generics.

The following classes were not converted, or were only partially converted:

- MultiMap and derivatives: MultiMap with generics breaks the 
java.util.Map contract, so only partial conversion was possible.
- All TransformedXXX collections: These classes break the 
java.util.Collection contract (or the java.util.Map contract, as 
appropriate) once generics are added. They were not converted to support 
generics at all.

We are considering adding MorphCollection, MorphMap, MorphSet, etc. 
interfaces to support MultiMaps and TransformedXXX collections. These 
interfaces would be the same as their non-morph counterparts, but 
'getting' would be templated independently of 'setting/adding'. For 
example, the MultiMap<K,V> interface would extend 
MorphMap<K,V,Collection<V>>. However, this is a large step as it would 
move these collections out from under the standard collection interfaces 
defined in java.util. We welcome any suggestions regarding this.

The collections pass all the unit tests. We have released it as a beta, 
but plan to move quickly towards a final release. We look forward to any 
suggestions and feedback from the community.

Sincerely,

 Matt Hall and John Watkinson

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

Re: Commons-Collections enhanced with Java Generics Support

[Mattias J <ma...@expertsystem.se>]

>>In summary, I don't think the number of people interested in 1.5 features 
>>will increase while Commons Collections developers just sit around waiting...
>Thats not fair.
>We do what we can and mostly in our free time. And its also your 
>(contributor) job to push a project forward - for sure what you have done now.

Surely I didn't mean "...doing nothing", I just meant not supporting JDK 
1.5 features until enough people are likely to want them.
My apologies if anybody was offended.

>But I wonder if we could let the jdk 1.3 behind us and move on to jdk 1.5 
>by allowing backward compatiblity with retroweaver.

AFAIK generics is only a compile time feature, no type checking is done 
during runtime, so a generics supporting JAR should be possible to use with 
older JDKs.
I have not looked at the Collections API over at sf.net, but possibly other 
things have changed to be able to add the generics support, which would 
make this library behave differently than the original one, on an older JDK.

   /Mattias Jiderhamn 


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

Re: Commons-Collections enhanced with Java Generics Support

[Thomas Dudziak <to...@gmail.com>]

> But I wonder if we could let the jdk 1.3 behind us and move on to jdk
> 1.5 by allowing backward compatiblity with retroweaver.
> At least with new to create x.0 branches.
> For sure that forbid us to use any new api feature, but we can use
> generics and some other new programming style stuff.

Especially for components like commons-collections, IMO it is quite
important to support JDKs as far back as 1.2 (and additional ones like
J2ME), if not even 1.1.

Tom

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

RE: Commons-Collections enhanced with Java Generics Support

[James Carman <ja...@carmanconsulting.com>]

Retroweaver's documentation specifically says that it allows you to develop
on 1.5 and deploy on 1.4.  I don't think it supports 1.3 and below.  Anyone
know for sure?

-----Original Message-----
From: Mario Ivankovits [mailto:mario@ops.co.at] 
Sent: Tuesday, May 24, 2005 11:43 AM
To: Jakarta Commons Developers List
Subject: Re: Commons-Collections enhanced with Java Generics Support

Mattias J wrote:
>> There is also the question of how large the generic collections
>> community will be. There aren't yet a whole lot of projects coding to
>> 1.5 as far as I know.
We use JDK 1.5 since the 1.5.0_01 is out and already use it in 
productive environments.
Dont know how large the community is, but I cant await to get more and 
more libraries supporting 1.5.
> In summary, I don't think the number of people interested in 1.5 
> features will increase while Commons Collections developers just sit 
> around waiting...
Thats not fair.
We do what we can and mostly in our free time. And its also your 
(contributor) job to push a project forward - for sure what you have 
done now.


But I wonder if we could let the jdk 1.3 behind us and move on to jdk 
1.5 by allowing backward compatiblity with retroweaver.
At least with new to create x.0 branches.
For sure that forbid us to use any new api feature, but we can use 
generics and some other new programming style stuff.

---
Mario


---------------------------------------------------------------------
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: Commons-Collections enhanced with Java Generics Support

[Mario Ivankovits <ma...@ops.co.at>]

Mattias J wrote:
>> There is also the question of how large the generic collections
>> community will be. There aren't yet a whole lot of projects coding to
>> 1.5 as far as I know.
We use JDK 1.5 since the 1.5.0_01 is out and already use it in 
productive environments.
Dont know how large the community is, but I cant await to get more and 
more libraries supporting 1.5.
> In summary, I don't think the number of people interested in 1.5 
> features will increase while Commons Collections developers just sit 
> around waiting...
Thats not fair.
We do what we can and mostly in our free time. And its also your 
(contributor) job to push a project forward - for sure what you have 
done now.


But I wonder if we could let the jdk 1.3 behind us and move on to jdk 
1.5 by allowing backward compatiblity with retroweaver.
At least with new to create x.0 branches.
For sure that forbid us to use any new api feature, but we can use 
generics and some other new programming style stuff.

---
Mario


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

Re: Commons-Collections enhanced with Java Generics Support

[Mattias J <ma...@expertsystem.se>]

At 2005-05-24 17:11, Simon Kitching wrote:
>There is also the question of how large the generic collections
>community will be. There aren't yet a whole lot of projects coding to
>1.5 as far as I know.

Assuming this statement is true (which I am not too sure about), the fact 
that many Open Source project do not yet support 1.5 features - like 
generics - might actually be the reason people have not yet upgraded. Put 
in another way; good and useful Open Source projects (like Jakarta Commons) 
supporting JDK 1.5 may motivate more people to upgrade to JDK 1.5.

 From the other perspective, for those of us that *do* use JDK 1.5 (and 
have done so for a while now...), the fact that Commons Collections does 
not support generics may motivate us to use the standard java.util.* 
collections, or some proprietary ones, instead.

In summary, I don't think the number of people interested in 1.5 features 
will increase while Commons Collections developers just sit around waiting...

  /Mattias Jiderhamn 


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

RE: Commons-Collections enhanced with Java Generics Support

[Michael Heuer <he...@acm.org>]

James Carman wrote:

> Suppose we do want to further pursue this (I think we should).  How would
> you recommend we set up the project?  Should we branch commons-collections
> off and start doing releases off of the JDK5 branch along side the main
> branch?

With a nod to "Rules for Revolutionaries" [1] I think it makes the most
sense to branch commons-collections.  This should be a lot easier process
now that the repository is in subversion.

The biggest obstacle to overcome is the lack of interested commons
committers to coordinate non-Apache developers, to merge different
implementations (there is a second 1.5 collections implementation at
collections15.sourceforge.net), and address some of the problem areas in
the generic conversion process, e.g. MultiMap.

   michael

[1]  http://incubator.apache.org/learn/rules-for-revolutionaries.html


> -----Original Message-----
> From: Simon Kitching [mailto:skitching@apache.org]
> Sent: Tuesday, May 24, 2005 11:12 AM
> To: Jakarta Commons Developers List
> Subject: Re: Commons-Collections enhanced with Java Generics Support
>
> On Tue, 2005-05-24 at 16:05 +0200, Thomas Dudziak wrote:
> > On 5/24/05, James Carman <ja...@carmanconsulting.com> wrote:
> > > Why can't we host this project at ASF?  Couldn't we create a new branch
> for
> > > JDK5 collections or something?
> >
> > +1, though I'd prefer the simple solution of two jars, one for pre-1.5
> > and one for 1.5 which contains the generics-support (either version or
> > add-on jar). This would prevent divergences in future versions as only
> > one codebase has to be supported.
>
> The major reason the project was developed on sourceforge is that the
> people who wanted to do the implementation were not commons committers,
> and no commons committers had time to manage the project.
>
> I don't know whether the developers (John/Matt) are even interested in
> the project being merged back into apache at the moment.
>
> But if they were, then in order for it to become a commons project
> (including being a branch of the existing collections project) either
> some existing commons committers would need to volunteer to commit
> patches submitted (including being responsible for the quality,
> licensing, and ensuring longterm support etc) or some/all of the
> generics project developers would need to be elected as commons
> committers.
>
> But we can't just elect someone as a commons committer without knowing
> the quality of their work or their ability to work well within commons
> (esp. having plenty of patience ;-). I think it very likely that
> Matt/John would be fine additions to the commons team, but we just don't
> know them yet (at least I don't). If someone had the time to check the
> collections.sf.net project mail list and review the existing code
> thoroughly this might be enough to give a +1 on this issue. Or if they
> have a track record with some other large open-source project. Otherwise
> the project really needs a few commons committers to work with them for
> a month or two until we can feel comfortable about electing them.
>
> There is also the question of how large the generic collections
> community will be. There aren't yet a whole lot of projects coding to
> 1.5 as far as I know. That would mean that it might be hard to ensure a
> pool of interested developers for this project that would continue
> maintenance. And that would be bad - commons doesn't need any more
> zombie projects than it already has. Then again I may be wrong; there
> might be huge demand for this. Or Matt/John may be enthusiastic enough
> to provide maintenance over the next year or two until java 1.5 becomes
> more prevalent. Checking the sf project forums should provide some
> evidence of whether there is a solid user community for this project or
> not. Certainly a pool of only two developers is a little fragile for
> long-term support if there is only a small user pool to draw new
> developers from.
>
> Note that I'm not saying it's impossible to bring this project into
> commons if Matt/John want to. And I certainly don't mean any offence to
> Matt/John, who have clearly put a lot of effort into writing code that
> is available for free and are therefore "good guys" by any definition.
> But these are issues that need to be addressed before adopting this code
> into commons.
>
> In the meantime, though, I see no harm in making sure we have plenty of
> references from commons to the collections.sf.net project (see, there's
> one!) from the commons site, wiki, etc. We can make sure people who
> might visit commons-collections are made aware of the generics version
> and then those people can make up their own minds about which code base
> they want to use. That's just being friendly and helpful.
>
> And there's nothing *wrong* with projects on sourceforge anyway.
>
> If you want to address some of these issues and push for generic
> collections in commons then go ahead and put a case that addresses the
> above issues.
>
>
> Regards,
>
> Simon
>
>
> ---------------------------------------------------------------------
> 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

RE: Commons-Collections enhanced with Java Generics Support

[James Carman <ja...@carmanconsulting.com>]

Simon,
Suppose we do want to further pursue this (I think we should).  How would
you recommend we set up the project?  Should we branch commons-collections
off and start doing releases off of the JDK5 branch along side the main
branch?  Or, would you recommend creating an entirely new commons project?
Or, would you recommend creating a
org.apache.jakarta.commons.collections.jdk5 package with the new classes in
them and set up the build to conditionally compile them only if using JDK5?


James

-----Original Message-----
From: Simon Kitching [mailto:skitching@apache.org] 
Sent: Tuesday, May 24, 2005 11:12 AM
To: Jakarta Commons Developers List
Subject: Re: Commons-Collections enhanced with Java Generics Support

On Tue, 2005-05-24 at 16:05 +0200, Thomas Dudziak wrote:
> On 5/24/05, James Carman <ja...@carmanconsulting.com> wrote:
> > Why can't we host this project at ASF?  Couldn't we create a new branch
for
> > JDK5 collections or something?
> 
> +1, though I'd prefer the simple solution of two jars, one for pre-1.5
> and one for 1.5 which contains the generics-support (either version or
> add-on jar). This would prevent divergences in future versions as only
> one codebase has to be supported.

The major reason the project was developed on sourceforge is that the
people who wanted to do the implementation were not commons committers,
and no commons committers had time to manage the project.

I don't know whether the developers (John/Matt) are even interested in
the project being merged back into apache at the moment.

But if they were, then in order for it to become a commons project
(including being a branch of the existing collections project) either
some existing commons committers would need to volunteer to commit
patches submitted (including being responsible for the quality,
licensing, and ensuring longterm support etc) or some/all of the
generics project developers would need to be elected as commons
committers.

But we can't just elect someone as a commons committer without knowing
the quality of their work or their ability to work well within commons
(esp. having plenty of patience ;-). I think it very likely that
Matt/John would be fine additions to the commons team, but we just don't
know them yet (at least I don't). If someone had the time to check the
collections.sf.net project mail list and review the existing code
thoroughly this might be enough to give a +1 on this issue. Or if they
have a track record with some other large open-source project. Otherwise
the project really needs a few commons committers to work with them for
a month or two until we can feel comfortable about electing them.

There is also the question of how large the generic collections
community will be. There aren't yet a whole lot of projects coding to
1.5 as far as I know. That would mean that it might be hard to ensure a
pool of interested developers for this project that would continue
maintenance. And that would be bad - commons doesn't need any more
zombie projects than it already has. Then again I may be wrong; there
might be huge demand for this. Or Matt/John may be enthusiastic enough
to provide maintenance over the next year or two until java 1.5 becomes
more prevalent. Checking the sf project forums should provide some
evidence of whether there is a solid user community for this project or
not. Certainly a pool of only two developers is a little fragile for
long-term support if there is only a small user pool to draw new
developers from.

Note that I'm not saying it's impossible to bring this project into
commons if Matt/John want to. And I certainly don't mean any offence to
Matt/John, who have clearly put a lot of effort into writing code that
is available for free and are therefore "good guys" by any definition.
But these are issues that need to be addressed before adopting this code
into commons.

In the meantime, though, I see no harm in making sure we have plenty of
references from commons to the collections.sf.net project (see, there's
one!) from the commons site, wiki, etc. We can make sure people who
might visit commons-collections are made aware of the generics version
and then those people can make up their own minds about which code base
they want to use. That's just being friendly and helpful.

And there's nothing *wrong* with projects on sourceforge anyway. 

If you want to address some of these issues and push for generic
collections in commons then go ahead and put a case that addresses the
above issues.


Regards,

Simon


---------------------------------------------------------------------
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: Commons-Collections enhanced with Java Generics Support

[Simon Kitching <sk...@apache.org>]

On Tue, 2005-05-24 at 16:05 +0200, Thomas Dudziak wrote:
> On 5/24/05, James Carman <ja...@carmanconsulting.com> wrote:
> > Why can't we host this project at ASF?  Couldn't we create a new branch for
> > JDK5 collections or something?
> 
> +1, though I'd prefer the simple solution of two jars, one for pre-1.5
> and one for 1.5 which contains the generics-support (either version or
> add-on jar). This would prevent divergences in future versions as only
> one codebase has to be supported.

The major reason the project was developed on sourceforge is that the
people who wanted to do the implementation were not commons committers,
and no commons committers had time to manage the project.

I don't know whether the developers (John/Matt) are even interested in
the project being merged back into apache at the moment.

But if they were, then in order for it to become a commons project
(including being a branch of the existing collections project) either
some existing commons committers would need to volunteer to commit
patches submitted (including being responsible for the quality,
licensing, and ensuring longterm support etc) or some/all of the
generics project developers would need to be elected as commons
committers.

But we can't just elect someone as a commons committer without knowing
the quality of their work or their ability to work well within commons
(esp. having plenty of patience ;-). I think it very likely that
Matt/John would be fine additions to the commons team, but we just don't
know them yet (at least I don't). If someone had the time to check the
collections.sf.net project mail list and review the existing code
thoroughly this might be enough to give a +1 on this issue. Or if they
have a track record with some other large open-source project. Otherwise
the project really needs a few commons committers to work with them for
a month or two until we can feel comfortable about electing them.

There is also the question of how large the generic collections
community will be. There aren't yet a whole lot of projects coding to
1.5 as far as I know. That would mean that it might be hard to ensure a
pool of interested developers for this project that would continue
maintenance. And that would be bad - commons doesn't need any more
zombie projects than it already has. Then again I may be wrong; there
might be huge demand for this. Or Matt/John may be enthusiastic enough
to provide maintenance over the next year or two until java 1.5 becomes
more prevalent. Checking the sf project forums should provide some
evidence of whether there is a solid user community for this project or
not. Certainly a pool of only two developers is a little fragile for
long-term support if there is only a small user pool to draw new
developers from.

Note that I'm not saying it's impossible to bring this project into
commons if Matt/John want to. And I certainly don't mean any offence to
Matt/John, who have clearly put a lot of effort into writing code that
is available for free and are therefore "good guys" by any definition.
But these are issues that need to be addressed before adopting this code
into commons.

In the meantime, though, I see no harm in making sure we have plenty of
references from commons to the collections.sf.net project (see, there's
one!) from the commons site, wiki, etc. We can make sure people who
might visit commons-collections are made aware of the generics version
and then those people can make up their own minds about which code base
they want to use. That's just being friendly and helpful.

And there's nothing *wrong* with projects on sourceforge anyway. 

If you want to address some of these issues and push for generic
collections in commons then go ahead and put a case that addresses the
above issues.


Regards,

Simon


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

RE: Commons-Collections enhanced with Java Generics Support

[James Carman <ja...@carmanconsulting.com>]

I don't think I understand your proposal.  Are you saying that we should
just put the classes with generics support into the HEAD branch of the
source repository?  

-----Original Message-----
From: Thomas Dudziak [mailto:tomdzk@gmail.com] 
Sent: Tuesday, May 24, 2005 10:06 AM
To: Jakarta Commons Developers List
Subject: Re: Commons-Collections enhanced with Java Generics Support

On 5/24/05, James Carman <ja...@carmanconsulting.com> wrote:
> Why can't we host this project at ASF?  Couldn't we create a new branch
for
> JDK5 collections or something?

+1, though I'd prefer the simple solution of two jars, one for pre-1.5
and one for 1.5 which contains the generics-support (either version or
add-on jar). This would prevent divergences in future versions as only
one codebase has to be supported.

Tom

---------------------------------------------------------------------
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: Commons-Collections enhanced with Java Generics Support

[Thomas Dudziak <to...@gmail.com>]

On 5/24/05, James Carman <ja...@carmanconsulting.com> wrote:
> Why can't we host this project at ASF?  Couldn't we create a new branch for
> JDK5 collections or something?

+1, though I'd prefer the simple solution of two jars, one for pre-1.5
and one for 1.5 which contains the generics-support (either version or
add-on jar). This would prevent divergences in future versions as only
one codebase has to be supported.

Tom

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

RE: Commons-Collections enhanced with Java Generics Support

[James Carman <ja...@carmanconsulting.com>]

Why can't we host this project at ASF?  Couldn't we create a new branch for
JDK5 collections or something?

-----Original Message-----
From: John Watkinson [mailto:commons.10.pents90@spamgourmet.com] 
Sent: Monday, May 23, 2005 12:10 PM
To: commons-dev@jakarta.apache.org
Subject: Commons-Collections enhanced with Java Generics Support

Dear Jakarta Commons developers,

We are pleased to announce that we have enhanced the Commons-Collections 
with Java 1.5 generics support! We have the results hosted on SourceForge:

http://collections.sf.net

We have done our utmost to maintain the exact same functionality as 
Collections 3.1. We have eliminated all deprecated classes that were 
scheduled for removal in 4.0. Furthermore, we have deprecated all the 
TypedXXX classes since they are made obsolete by generics.

The following classes were not converted, or were only partially converted:

- MultiMap and derivatives: MultiMap with generics breaks the 
java.util.Map contract, so only partial conversion was possible.
- All TransformedXXX collections: These classes break the 
java.util.Collection contract (or the java.util.Map contract, as 
appropriate) once generics are added. They were not converted to support 
generics at all.

We are considering adding MorphCollection, MorphMap, MorphSet, etc. 
interfaces to support MultiMaps and TransformedXXX collections. These 
interfaces would be the same as their non-morph counterparts, but 
'getting' would be templated independently of 'setting/adding'. For 
example, the MultiMap<K,V> interface would extend 
MorphMap<K,V,Collection<V>>. However, this is a large step as it would 
move these collections out from under the standard collection interfaces 
defined in java.util. We welcome any suggestions regarding this.

The collections pass all the unit tests. We have released it as a beta, 
but plan to move quickly towards a final release. We look forward to any 
suggestions and feedback from the community.

Sincerely,

 Matt Hall and John Watkinson

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