commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Laurent Brucher" <>
Subject RE: Commons-Collections enhanced with Java Generics Support
Date Thu, 26 May 2005 22:07:59 GMT
Hi John,

First off, thanks for the time and effort you guys have put into the port.
Having joined Chris recently on the Collections15 port, I understand the
work that
is required to get this done.

Some comments and thoughts below.

> Our approach was to shoot for supporting generics in the 
> majority of the 
> classes. This was because we wanted to begin using the collections in 
> 1.5 in our own projects immediately, and there was no 
> existing solution 
> for us. Those classes that did not lend themselves well to 
> generics were 
> either not converted or were only partially converted. This way, the 
> software worked right away and was a clear improvement over the 
> non-generic collections. We agree that it has some 
> short-comings in the 
> partially-/non-converted areas and we look forward to working with 
> everybody to resolve those in the best way possible.
I understand your needs to have something quick that fits your particular
But I feel like the ported [collections] should contain all of the current
features and
classes at the time it is released to the public, as you mentioned at the
end of your email.

> Yes, we feel that the some of the internal implementations are 
> well-converted, but not all. We look forward to improving the use of 
> generics in those classes and throughout the source. These 
> refactors are 
> important, but will not change the experience for the users 
> of the library.

Well, I'd say that if the plan is to rework the internal implementation
then I think this should be done first before releasing to public, saving
from potential bug fixes, etc. that may appear during the rework.

> ---
> 3. Here's my biggest worry. The unit tests in 
> don't 
> appear to have been modified to reflect the generification of 
> the APIs. 
> The 100% success rate of the unit tests is therefore 
> misleading, as it's 
> more of an indication that the original commons-collections code on 
> which the port was based doesn't fail any 
> of its unit 
> tests. What's missing in the unit tests is an attempt to exercise the 
> generic modifications made to the APIs. Whilst updating the 
> unit tests 
> in, a fair number of minor errors where 
> uncovered. 
> They were typically problems whereby it became apparent when 
> writing the 
> unit tests that the generic arguments of various methods weren't 
> sufficiently flexible. I'm worried that since the unit tests in 
> don't exercise the generic modification that have 
> been made, the modifications may not have been exercised at all.
> ---
> On this point, I don't entirely agree. The behavior of a class is the 
> same at runtime regardless of whether the user used generics in the 
> source code or not. Any errors in our addition of generics to the 
> collections will manifest themselves at compile-time, not 
> runtime. Now, 
> such issues are important, and we should make sure that each 
> method of 
> each collection is defined consistently from a generics point 
> of view. 

Indeed, things will be the same at runtime. But I also feel that it is
essential to have unit tests written specifically for generics to ensure
the API is valid at compile time. This is what users will first run into
when moving to the new [collections].
Having said that and having gone through a bunch of them already, converting
those unit tests to use generics is far from being a straightforward task.
But gotta be done.

> Chris, thanks for these points. We agree that there should not be 
> duplicated effort on this project, and we look forward to open 
> collaboration on this. More work is certainly required to bring those 
> straggling non-generic collections in to the fold, but we 
> emphasize an 
> approach that retains the full, working funtionality of the 
> collections 
> during these early releases. That way, developers can use the 
> package, 
> get used to the generic versions of the collections, and 
> provide us with 
> valuable feedback.

I agree with that but I also remember Stephen's word recently saying that
the [collections] must not only be 'clean' but also be perceived to be
I do think it is important that early adopters feel comfortable with the
API once they start using them with generics and not only using the JAR with
previous, non-generic, code.

Finally, I do agree with both Chris and yourself that combining efforts is
certainly a better idea than duplicating them.
Looking forward to this then :o)

Laurent Brucher.

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

View raw message