Like A Girl

Pushing the conversation on gender equality.

Code Like A Girl

Common libraries in Java and where to find them

Image taken from giphy — http://gph.is/2dtWdXD

There’s a lot of utility Java libraries that many projects use as a matter of fact. However, some developers still either remain blissfully unaware that they exists, or “do not want to include too many unnecessary dependencies”, or just don’t know the extent of the APIs that are already included and can be used — but alas, remain untouched. So, what are our options?

Apache commons-lang3.

  • Why: a lot of methods are Null-safe;
  • The code becomes more readable;
  • They are already tested and guaranteed to work as declared.

This last point isn’t something to sneer at. Yes, it is not difficult to write a utility method (as a rule). Yes, you can extract it in shared library. Yes, you can reuse it. But:

  • You will have to support the code and tests on your own;
  • Once you share it to other projects and teams, it is your responsibility to not introduce breaking changes or deprecate the methods properly and gradually;
  • You will have to notify everyone on your team or other teams about these libraries and how to use them;
  • And you will have to repeat the process in every new company/project you join.

Sounds stupid right? Why would anyone want to do that? Looks like I am trying to prove an axiom here. So, let’s instead look at what the most common utility modules and methods are in Apache commons-lang3.

isBlank()/isNotBlank(), isEmpty()/isNotEmpty() etc.
Why is it a bonus that we have both sides of the coin — meaning the methods like isSomething()/isNotSomething():

Not all code is created equal.

This is three ways how we can add a prefix to a string: with a null check, using StringUtils.isBlank(), or using StringUtils.isNotBlank(). Note how the code becomes shorter and more readable with a utility method even in such a simple example. But what I think is best is the last option, StringUtils.isNotBlank(). What is good about it is that you can hardly put it in there by mistake — but with the negation like !StringUtils.isBlank(), it is quite easy to do. I think every developer had his share of bugs due to inadvertently inverted conditions — I certainly had mine. With utility methods for both cases, the positive and the negative, it is less easy to invert the condition by mistake.

And by the way, if we really need to add a prefix there’s already StringUtils.prependIfMissing(String s, String prefix)! So, please look into StringUtils: there’s more goodies there.

  • ExceptionUtils
    There was an actual piece of code I met in the project:
Completely unnecessary piece of code.

What is wrong with it? Well, first of all, it is not null-safe; it is recursive, which is great for programming interviews but much less so for production code; and it has all of the drawbacks of a self-invented bicycle: you have to write it, test it, support it, share it etc. But there’s a rule of thumb which you should know, and it sounds like this.

If you feel like something should be in a library, it probably already is.

In this case, the replacement code extracting a root cause from the exception would look like this:

Apache Commons-Collections

  • CollectionUtils isEmpty()/isNotEmpty(), isEqualCollection(), isSubCollection(), permutations(), removeAll()/retainAll() etc.
  • There’s methods for merging collections, checking inclusion, subtraction, intersection, transformations and filterings. However, the last two are less relevant now that there’s Java 8 with its map() and filter() over a stream.
  • MapUtils (multi-value map, ordered map, unmodifiable map etc. factory methods, transformers, value extractors etc.)
  • FluentIterable — a really powerful fluent API for manipulating collections. Do not confuse with FluentIterable from Guava — though they are pretty similar!
  • And a lot of other stuff — just look around!

Google Guava library — a huge collection of goodies with a large guide here. It is great for basically everything, from collections to exceptions to optionals to multithreading helpers, but every aspect of it deserves its own article. However, I would say that after Java 8, we should prefer using Java’s inbuilt possibilities whenever possible, and turn to Guava when there’s something missing.

And of course Spring Framework library also has a set of its own utility classes. For example:

  • Also has StringUtils — but much less extensive and recommended for internal use only;
  • Also has CollectionUtils — but not as extensive as Apache or Google Guava;
  • some StreamUtils for dealing with the streams;
  • It also might be useful to look at Assert utility class which can very well replace Guava’s Preconditions for the uses of validating — if, for example, you don’t want or need to include Guava as a dependency but you are already using Spring Framework.

There’s a lot of libraries out there, but there’s an unwritten eleventh commandment for all the developers, and it is this:

Know thy tools.

We can’t know all, but we can know something, or at least try. So please look out for what’s there. It is great if you can reinvent a wheel — but in most cases, you just need to know how to use one.

Originally posted at https://mchernyavska.wordpress.com/2017/11/05/common-libraries-in-java-and-where-to-find-them/