commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Kestle <>
Subject Re: [COLLECTIONS] status of 1.5 branch
Date Sun, 28 Oct 2007 21:03:46 GMT
The plan is for non backwards compatibility, as there are too many 
things that don't make sense for generics, and some things that plain 
don't work.  The Map coercion methods become silly, and TransformedMap 
can't conform to the map interface in it's current form (is that the 
right one?).

Having said that, I am planning (in my zero time - probably until 
christmas :( ), to have a "1.4 upgrade" generics collections that has 
minimal changes (where necessary) and will provide a general drop in 
replacement.  The main release will be a clean generics release without 
deprecation, for those wanting to get started afresh.  BTW, absolutely 
none of the trunk's deprecated API will make it anywhere into the 
generics project (it's gone already...).  [You're using it to make a 
jump, so *you're going to* make the jump].

So, there will be minimal binary changes, but you will likely have to 
recompile (some CollectionUtils void methods will now return something 
Some classes will need revamping, and potentially entirely renamed to 
ensure that there is no conflict with different prior behaviour - I 
haven't really looked at the maps.

NB!!!  Don't submit patches for CollectionUtils --- I have it 90% 
complete, and will find time to do the other 10% if people want to see 
it (are people actually using the generics branch? I am, but then I know 
it's as good as my own code :)

I don't think it will be too difficult to strip out deprecated methods 
at build time, but will probably take a bit of time to get right.

Yeah, maybe I will try and find some more time... but generally, I work 
on it as I need it's [generic] features.

+1 Wiki page, and for someone to summarise the mailing list.  I believe 
this message contains the major consensus from the previous discussions 
(actually, having a minimal 1.4 upgrade-deprecated jar is my idea - 
simply because it'll be easier to do a double [remove 
deprecation->upgrade] jump than to do it all in one)



Requests for clarification welcome.

James Carman wrote:
> Maybe we should set up a wiki page to discuss this 1.5 problem for
> collections (and maybe other projects).  We should outline why we have
> been reluctant as of yet to "genericize" collections (binary
> compatibility, serialization issues, etc.).  That way folks don't have
> to try to search through the archives or try to remember (I'm having a
> hard time remembering the whole conversation) all the details.
> On 10/25/07, Brian A. Egge <> wrote:
>> Hi,
>> What's the status of the JDK 1.5 branch?  It seems the developers are split as to
if it's a good thing, and if so, if the API should be different or the same.  Most advice
I see says to use the collections15 project on SourceForge.
>> What I would like, is a drop in replacement, with binary backwards compatibility
with the 1.4 version.  I want everything in the same package name, and to have the same names.
 If there are some additional methods, then that would be ok.  Basically, I found upgrading
the JDK collections has been rather painless.  My 1.4 projects work fine in 1.5, and if I
want to change my code to use generics I can.  Eclipse even will help me out with this.  Because
Java decided to use type erasure, it's possible to have a library with generics, that works
identically to one without.
>> I ran clirr against the 1.5 branch, comparing it to the 3.3 snapshot in the trunk.
 It reported 93 differences.  I'm happy to spend some time creating patches for this project,
if there are other people (read committers) who have the time to review and apply the patches,
and also share my vision of a compatible library.
>> Commons Collections is one of the most popular components within the Commons project,
and the main use of generics is within container classes, so I think it would be a real benefit
to get this project up to date.
>> -Brian
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

* <>*

*Stephen Kestle Software Engineer* <>
P: +64 9 638 0619
M: +64 27 453 7853
F: +64 9 638 0699
S: skestle <callto:skestle> <>

This e-mail and any attachments are intended only for the person to whom 
it is addressed and may contain privileged, proprietary, or other data 
protected from disclosure under applicable law. If you are not the 
addressee or the person responsible for delivering this to the addressee 
you are hereby notified that reading, copying or distributing this 
transmission is prohibited. If you have received this e-mail in error, 
please telephone us immediately and remove all copies of it from your 
system. Thank you for your co-operation.

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

View raw message