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 needs. 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 anyway, then I think this should be done first before releasing to public, saving them from potential bug fixes, etc. that may appear during the rework. > > --- > 3. Here's my biggest worry. The unit tests in > collections.sf.net 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 collections.sf.net 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 collections15.sf.net, 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 > collections.sf.net 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 clean. 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 their 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
