Commons Lang – Why?
A lot of useful software has come out of the Apache Foundation and its Jakarta project, but I’ve never been a fan of the Commons libraries. Aside from the questionable premise of Commons Logging, it was a disappointment with Commons Math that inspired the domain name for this site. It’s fair to say that Sun’s enhancements over the years to the standard libraries and Java language (e.g. generics, auto-boxing and enums) have obsoleted many of the Commons classes.
Today, at work, I discovered that some of the code in my current project depends on Commons Lang. This led me to investigate what exactly this library provides. I’ve been looking through the docs, through the source code and scratching my head in puzzlement at the utter wrong-headed pointlessness of much of this beautifully-commented folly. The stuff that’s not mind-bogglingly trivial is suspect in many ways.
The builder package is of dubious utility. The major IDEs will auto-generate efficient implementations of equals, hashCode and toString. The Commons solution for equals and hashCode means writing more code with additional runtime overhead. The security-violating, reflection-based option for implementing the equals method is especially daft.
The BooleanUtils class provides the following brilliantly redundant quartet of static utility methods: isTrue, isFalse, isNotTrue and isNotFalse. We’re just missing isEitherTrueOrFalse and isBothTrueAndFalse.
These criticisms are about things that are mostly harmless. The Commons Lang treatment of random numbers is less benign. A utility class provides static versions of most (but not all) of the useful methods from java.util.Random. These methods delegate to the very special Commons Lang RNG.
The Commons Lang RNG (JVMRandom) is remarkable in that it proves that the concept of “adding value” can be applied even when value is a negative quantity. JVMRandom is a sub-class of java.util.Random. Each of the interesting methods is over-ridden. Some are over-ridden to throw UnsupportedOperationException (and therefore prevent access to potentially useful functionality). Those that do still do something are over-ridden to generate all random values via Math.random() (Roedy Green has an explanation of why this isn’t sensible). The random boolean method is re-implemented to be (very slightly) biased in favour of false. In short, JVMRandom extends the imperfect but functional default RNG and makes it do less, more slowly and less correctly.
on June 29th, 2007 at 12:46 am
So what’s your point? Just because some classes (or even some projects) at commons are crap – all is crap? If you missed the useful stuff from commons I feel sorry for you. It saved me quite a bunch of time. Hell – this is open source. Better spend your time sending patches than writing posts like this. Or are you just a fan of useless bileblogs?
on June 29th, 2007 at 5:41 am
It s key to note that much of commons-lang predates the features therein being implemented in the standard library
Heck, it’s purpose was to provide features the standard library lacked. The number that have been pulled back in does it credit.
on June 29th, 2007 at 7:18 am
You might be right in some of your comments on commons-lang. I find stuff like StringUtls and ArrayUtils helpful.
I do not agree completely with you on this statement “…Sun’s enhancements over the years to the standard libraries and Java language (e.g. generics, auto-boxing and enums) have obsoleted many of the Commons classes”. Actually, Sun has been quite conservative with adding value on classes in the java.lang package. Nearly every project I’ve been on or a lot of the open-source ones I’ve used, have a StringUtils they’ve written themselves.
If using IDEA, try opening a project with many dependencies, hit Ctrl-N, check “Include non-project classes” and type “StringUtil”. There will be more than one, I can almost guarantee you.
I guess this is due to two things:
* sun being conservative
* Java not being dynamic enough to fix it yourself
In Ruby, I could just open up the String class and add new methods
on June 29th, 2007 at 9:37 am
Torsten, there’s no point in writing patches for code which (in my opinion) servces no useful purpose. The only way to improve JVMRandom would be to delete it and use java.util.Random instead. And yes, I am a fan of useless BileBlogs
Brian, you are absolutely correct, this is kind of the point I was making in the first paragraph. The redundancy of some of the classes is down to its age rather than incompetence.
Per, you may be right. I certainly have not looked at all of the classes. But the vast majority of the ones I did look at didn’t appear to offer much.
on June 29th, 2007 at 11:52 pm
Of course you are welcome to your opinion
Commons-lang reallly just represents a combination of the utility libraries that every good developer and development team writes.
Oh, and why BooleanUtils.isNotTrue ? Well write the code and see which is easier to understand:
if (!Boolean.TRUE.equals(myVariable)) { …}
if (BooleanUtils.isNotTrue(myVariable)) { …}
Personally, I find the latter *much* more readable and expressive of intent. Generally, avoiding nulls and the negate ! operator result in safer clearer code.
on June 30th, 2007 at 10:40 am
Good points I can immediately follow, especially regarding BooleanUtils! But as other said, many classes from the commons libs are very useful. Recently I replaced calls to Java encode and decode routines with the ones from commons codec. The latter run myriads of times faster!
So what would really help is if your appropriate criticism is forwarded to the regarding apache projects in order to make them better.
on June 30th, 2007 at 1:43 pm
I work at a company with 100+ java devs, with a “java support” team getting slashed one year (“those architects in their ivory tower are too expensive”) and recreated the next (“we need to on a common framework”).
In that unstable environment, Commons Lang and friends slowly replaced the StringUtils, BeanUtils, .. classes developed and “maintained” separately for each project. I love it just for that reason. They can do the job 10 times slower, I don’t care…
on June 30th, 2007 at 2:14 pm
Stephen, even ignoring the fact that auto-boxing makes BooleanUtils redundant, since I’m assuming this code pre-dates auto-boxing, is there really a need for both isFalse() and isNotTrue? If the argument is because the object may be null, I am unconvinced. I’d rather fail fast with a NullPointerException than hide the bug.
on June 30th, 2007 at 3:09 pm
Commons Lang is a little outdated. The only thing I really use it for is the full exception trace method… heh.
on July 5th, 2007 at 2:06 pm
I agree with Dan, Stephen, both your examples are very unclear, and can be simplified to if(myVariable) and if(!myVariable), and I doubt anyone could argue that any method calls are simpler than that.
on July 16th, 2007 at 11:25 pm
[...] previous post, about the Apache Commons libraries, and Commons Lang in particular, was slightly controversial and [...]
on November 26th, 2007 at 11:48 pm
[...] Apache Commons Math (regardless of the incidental mention Commons Math received in my previous rant against Commons Lang). Commons Math provides a lot of functionality that Uncommons Maths does not [...]