commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject Re: [collections] Cleanup of trunk
Date Wed, 04 Jul 2012 14:00:24 GMT
Hi Stephen,

Stephen Colebourne wrote:

> To clarify what I've said before, there are two user requirements here;
> - adding generics to the last release while maintaining compatibility
> - rethinking some APIs to get the best design features for Java 5+
> (non-compatible)
> ATM, no one is working on the first that I can see, yet that is what
> the existing user base actually wants. The users won't be able to
> upgrade to a non-compatible release, due to the fact that other open
> source projects depend on the current release.

Even the current code base is already beyond this goal. Some methods have 
already be renamed and it is no longer a drop in replacement. 

> Thus, for me, any non-compatible release is effectively a new project.
> It would be clearer to rename the project and start again at version
> 1.0 for the non-compatible codebase. Maybe [collectionsplus]. A lot
> clearer than what happened with [lang3].

Actually I was very satisfied with the lang3 approach. In our own projects 
we have been switched completely, normally just by exchanging the impoert 
statement. Nevertheless, we did not get rid of lang itself, but it is 
introduced by 3rd party stuff and will hopefully vanish completely over 

> Bear in mind that [lang] (version 2) and [collections] are number 6
> and 7 on the most downloaded artifacts list

Yeah, but what's new about this? With lang3, lang did not vanish and all the 
projects that use it, do not switch over night. I'd be really interested, 
how the number of downloads of lang and lang3 changed over time since lang3 
was released. Actually we already have now in the meanwhile 3rd party stuff 
that depends on lang3 - a clear indication for me.

> However, the big issue here is that the whole library will need
> rewriting for JDK 8 due to lambdas. So what does a non-compatible
> release now actually accomplish?

So wait for another 2 years for collections?

> Well, since I'm not being active, I'm not going to stop people. But I
> am trying to speak up for the users, who just want a compatible
> bug-fixed, generified version (even if it can't be fully generifed,
> some generics are better than none).
> Note that none of this is about Java 5 vs 6. Its about compatibility
> and what users actually want (remember the maven download stats!!).

Actually I doubt that you can argument here with the download stats. It is 
like arguing that all people driving a heavy used road will rather have a 
better pavement instead of one on a new trail with an additional lane.

If somebody really wants to create a generified binary compatible 
collections 3.x, it can be done on the branch and released as 3.3. 
Personally I am just not interested in making it. ;-)

- Jörg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message