commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Kestle <>
Subject Re: [collections] VOTE: Collections-java5 direction
Date Sun, 11 Mar 2007 21:21:09 GMT
Stephen Smith wrote:
>> 05. Re-naming classes and methods.  I think that names should be 
>> re-evaluated to make sure that they still make sense in the new 
>> code.   For example, with the singletons we have 
>> TruePredicate.getInstance(), but this becomes relatively silly when 
>> we have static imports.  There's only one getInstance() method that 
>> we can import per class.  Therefore it should be 
>> TruePredicate.getTruePredicate(), which will be simplified to the 
>> shorter getTruePredicate() in the code.
> That's an interesting idea, Stephen - I haven't considered the impact 
> of JSE5 static imports on the Singleton design pattern before. 
> However, I'd reserve a +1 on it solely because I'm a little worried as 
> to how far we're going to open this "reboot" can of worms.
I say go the whole way - however, in voting for 01. (deprecated 
methods), I would also be inclined to deprecate the old-standard way of 
doing things. 

If we go the way of a renamed package, we can always have a 
compatibility jar that will map the old to the new stuff.  However, I 
really like the namespace - I'd propose that we keep the package name 
the same, and add a org.apache.commons.collections-compat package for 
transitional utilisation.  That's pretty easy to do with a find replace 
in source (we've broken binary compatibility anyhow).

Otherwise we could make it a two-stage/option release.  There will be a 
compatibility migration release (throughout development), which sets the 
new direction, but retains old (and now-deprecated) methods, and then 
once that's stable, we can remove all the old-standard methods 
completely from the trunk and release that as well - both would be 
maintained in parrallel.  Even better would be to have an automated 
build that is able to do this.  The compatibility build would only be 
for the first version.

Both options have their ugliness and pain, but I think it's short term 
pain for long term gain.  How much of a better gift can we give future 
developers than a beautiful, well crafted api?  In my projects, order of 
import is (log4j, collections, easymock, joda-time).  Collections is a 
biggie, and probably gets used (or at least should be) in well over half 
of all projects.
> For example. if we're really going to push the boat out on this, what 
> about hiding public constructors in static utility classes? It's the 
> sort of thing CheckStyle whines about, and normally with good reason. 
> I've never understood why CollectionUtils#CollectionUtils is public, 
> even with a comment along the lines of "should not normally be used". 
> If every method is static (and the class is therefore potentially 
> finalised), when would it ever be used?
Hah - snap!  I was just about to come back and talk about checkstyle in 
another thread - is there an apache checkstyle convention that we are 
able to use for this to ensure the code is properly formatted?  I 
support the above, but would also prefer to go a bit further (e.g. if 
statements [that represent exceptional conditions] with return 
statements should not be followed with an else, as the "else" should 
really be the normal flow of the method).

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

View raw message