Stephen Kestle wrote:
Stephen Smith wrote:
I think there's merit in simply porting generics to the current
Commons Collections 3.2 codebase, but I believe we could get better
bang for our buck by discussing how we might reboot Commons
Collections. I would suggest a moderately radical approach:
01. Removing all deprecated code - let's take the opportunity to
shrink the size of the Commons Collections JAR while we can.
+1
02. Removing (*not* deprecating) methods specifically related to type
safety pre-JSE5. I'm thinking of classes such as MapUtils here, whose
methods such as MapUtils#getDouble have probably had their day.
+1
03. Checking our test case coverage, although I don't remember off the
top of my head if Cobertura is plugged into standard Jakarta Commons
components. Question: do we want to upgrade our test cases to JUnit 4
as well?
I use junit 4, and it's a huge jump in productivity and readability.
TestNG has the feature of ordering tests really well and not executing
tests with failed dependencies (and also "other" testing such as DB
etc). However, I don't think we need the extra features, as Commons
[Collections] is very much small utility classes designed by
collaboration, so the tests should be relatively simple.
04. Porting generics into the remaining codebase.
+1
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.
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?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
