commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Smith <>
Subject Re: [collections] Generifying Collections
Date Wed, 25 Oct 2006 18:22:29 GMT
I agree on the latter point - that JSE5 is in some ways a complete shift 
in Java paradigm. Whatever solution is chosen going forward, +1 for a 
cross-Commons approach... otherwise figuring out compatibility between 
Commons JARs will become even tougher.

I dislike the idea of putting version numbers into package names, but I 
don't see a realistic alternative giving the fact that Java's handling 
of JAR manifest versioning isn't as rigorous as we might like for this 
sort of problem.

org.apache.commons.collection5.CollectionUtils is all well and good, but 
what happens when we migrate to Mustang? Do we go with 
Stephen Smith, MEng (Wales).

Stephen Colebourne wrote:
> From: Kris Nuttycombe <>
> James Carman wrote:
>>> I don't like forking all of commons together.  To say
>>> commons5-collections-1.0 doesn't work for me.  Then, we have to get 
>>> all of
>>> the commons projects to decide on "fork points."  Am I understanding (c)
>>> correctly?
>> I don't think there has to be commons-wide fork at all. I just see the 
>> name change at the commons level rather than the package level being an 
>> approach that can be useful to other packages, so that the other 
>> projects that will inevitably make the switch can do so in a uniform 
>> manner.
>> In the end, I'm most interested that whatever method is adopted be a 
>> solution that can work for all of the commons projects that may want to 
>> generify. BeanUtils could certainly be improved with generics, as could 
>> Lang and others. In my shop, at least, we've been using JDK5 for over a 
>> year now and the lack of progress towards creating generic versions of 
>> the Commons components bespeaks a bit of stagnation.  I've got the itch 
>> for generics across the board; I'd like to be able to scratch it.
> Yes. I regret using the word 'fork' now, as it has negative connotations. And I agree
that quite a few projects need generifications (or rather Java5-ification). Now I'm on JDK5
at work (and its been a massive pain upgrading) I'd like commons to support JDK5.
> Consider [lang] - a good proportion of [lang] is providing ways to support JDK5 features
on earlier JDKs. We might not choose to support them once we have a JDK5 version. The same
applies to [collections].
> The commons5 name is quite a nice way to express all this. Is it really much different
to how Tomcat manages J2EE versions? And I definitely do not think it involves forking the
whole of commons!!! Not sure where that idea comes from, but 'commons5' is just a naming conventinon
(and package name) for those projects which want a JDK5+ specific version.
> We need to remember why JDK5 is so important - its because its almost a whole new language.
Its not a small incremental step like prior upgrades. We should treat it as such. (Especially
as lots of big enterprises are perfectly happy on JDK1.4 and aren't planning to upgrade)
> Stephen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message