Results tagged “Apache Commons”

A few days ago I hit a problem while refactoring some legacy Java Code. Following my own advice to use safe and simpler library methods I changed the code-block

List<String> list = dao.getEntries(id);
if(list != null && list.size() > 1) {


List<String> list = dao.getEntries(id);
if(CollectionUtils.size(list) > 1) {

Should do the same, looks nicer and should be safer too, right? Imagine my confusion when suddenly several unit tests began failing at other parts of the code not directly related to this change. When I found out that this single line was the cause of the other errors I of course looked up the JavaDoc for CollectionUtils on Google. According to the docs at the size() method should return 0 when presented with a null collection. Things were very strange here. In fact, it took me a few days to find out what's wrong.

In fact, I did not recognize that the access to the JavaDoc was redirected to, which did not show the documentation of the latest stable CollectionUtils docs (as it did until a few weeks ago) but showed the version of the SVN tip. It took a roundtrip through the Apache Commons main page to find the correct JavaDoc page for the current stable 3.2.1 CollectionUtils at And, surprise surprise, there the API for the size() method looks a bit different: "Throws: java.lang.IllegalArgumentException - thrown if object is not recognised or null".
Well, so much for the praised null-safety of Apache Commons... In the current implementation, CollectionUtils.size() is of no use for me and I reverted the refactoring.

In the end I was a victim of partly my own assumptions for the null-safety of Apache Commons and partly a very weird redirection of the Google search result URL. I still have no idea why this URL suddenly gets redirected to a different version than it did until a few weeks ago but I hope that either Google soon updates its search result (unlikely as there are loads of references to this address) or Apache corrects it to its former destination. For the safety of users in my opinion the correct version which shows up should be the one of the latest stable version, not an arbitrary SVN version.

Lesson learned: also check version of JavaDoc if something smells fishy, even if it has been correct in the past.


Another quick addition to my Java Tips series. This instance deals again with adding some safety while reducing a bit of code clutter.


Use Commons ObjectUtils.toString() instead of directly calling toString() on an object if it may be null. This also allows for a alternate result if the object is null.



final String projectId = (request.getParameter("projectid") != null) ? request.getParameter("projectid").toString() : "";
final String roleId = (request.getParameter("roleid") != null) ? request.getParameter("roleid")
        .toString() : "DEFAULT";


final String projectId = ObjectUtils.toString(request.getParameter("projectid"));
final String roleId = ObjectUtils.toString(request.getParameter("roleid"), "DEFAULT");


Readability gain. Safety gain, as ObjectUtils methods are null-safe. The reduced code footprint eases recognition of the intention, which is even more significant if there should be a default text if the object instance is indeed null.




In the last few weeks I've got the chance to look into the sourcecode in a lot of different modules of the product our department is working on. The more code I had a look at the more a certain insight was forming in my head. What I saw when I looked at the different parts of the sourcecode from a lot of different people is, that it's cruical for the maintainability of code to know the advantages and possibilities of the frameworks you're working with. Otherwise you're going to reinvent the wheel over and over again. And I recognized many different wheels in this code.

We're working with Java here and among our used frameworks is also the Apache Commons. It's a framework which greatly eases the solving of common problems every Java developer faces every day. To give examples I'll focus on working with collections here. The Java framework itself has already some convenience methods available when working with Collection classes in the their generic interface classes (like Collection, List, Set or Map) but the Commons Collections Classes provides further methods which cover many day-to-day operations with their xyzUtil classes (see CollectionUtils or ListUtils for examples).

A lot of the operations I came across in our code deal with creation and manipulation of different collections, transforming from/to arrays, intersecting or summing them and so on. Lots of loops and different ways to solve always-repeating problems. With the utility-classes and methods from the frameworks we're using a lot of these sourcecode-parts can be reduced and simplified from up to a few dozend lines to just a few ones or in a lot of cases even a single line.

Not only does this reduction aid the readability and comprehensibility of the code it also makes it more robust as most of the framework-methods are already for example null-safe and thus take the burden of null-checks from the developer. And less code is easier maintainable than endless pages of difficult logic. Of course, the usage of frameworks also requires the developers who get at it later on to have at least a little knowledge of these but the invested time to get familiar with the framework almost always pays off manifold.

PS: Another extremely useful utility class in the Apache Commons is the StringUtils class. Just have a look at the impressive convenience methods in its interface and I bet there are many methods in there which you immediately could use at some places of your code.