StringUtils vs != null

Question

I encounter quite often very different String validations and we all know there are new libraries such as StringUtils. Can someone explain why for example StringUtils.isNotBlank(paymentTerm) is more or less preferred over paymentTerm != null?

Answer 1

I feel like the premise of this question is already an incorrect one. You should not have to check for null strings in most places -- in fact, I would argue that you should avoid using null whenever possible, but especially when another non-null sentinel value exists. And String already has a very good "empty" value: the empty string ("")!

If "" and " " need to be folded into the same value, then there's already a perfectly good method for that in the standard library: .trim(). However, .trim(), being an instance method on String, only works on non-null strings. This isn't necessarily a bad thing!

If null and "" mean different things for you, then I would argue that your data model is too complex, and you should be using some other wrapper class rather than using String directly. If null and "" mean the same thing, then you should pick one or the other, and use it consistently. That may mean the need for a few != null checks, but if you find yourself needing an isNullOrEmpty or isNotBlank helper function frequently throughout your codebase, I would say that that's a code smell and you really should work on fixing the underlying data model issues rather than worrying about a tiny helper function.

What does that mean? In the Avoiding != null statements question, the top-voted answer points out that there are really only two kinds of instances where a value can be null: either (1) null is a valid value, or (2) null isn't a valid value.

Case (2) isn't very interesting. Null is not a valid value, so we shouldn't try to deal with it. If anything, we simply throw an exception if we encounter it. Otherwise we ignore it, and let a NullPointerException happen "naturally". It's not supposed to be null, so by definition finding a null is an exceptional situation.

If null is a valid value, then it means null has a semantic meaning. Most likely it means that a value is "not present" or "not valid". There are two sub-cases here: (1a) null means the same thing as the empty string, or (1b) it means something different.

If you have case (1b), then I would argue that you need a new entity in your domain model. For example, you could create a class like PaymentTerm which has separate .isValid() and .isPresent() methods, as well as a .asString() accessor to get the string value if it is present. (The are a lot of possible ways to make a PaymentTerm class, with lots of possible tradeoffs: the point is not that you need this specific form, but that you need something more than a raw String, something that you can hang methods off of, because this thing is now a first-class entity in your domain model.)

If you have case (1a), then null and the empty string both mean the same thing, semantically. But they are very different syntactically! The empty string already has an instance method to check for it (.isEmpty()) and can be safely stored, passed around, compared to other strings, etc.

So case (1a) has two possible solutions: (1a.1) you pass around both null and the empty string, and everywhere you have to check for either, or (1a.2) you normalize nulls to empty strings at the soonest opportunity, and then treat null as an invalid value, and use the empty string everywhere. Depending on your input format, you may even get this behavior "for free" (e.g. an empty text box naturally has the empty string as a value, not null).

My argument is that case (1a.1) is a code smell. Rather than passing around both null and the empty string, and frequently checking for both (either manually or with a method like isNullOrEmpty or isNotBlank), you should try to move into case (2) or case (1a.2).

Note that this answer actually implies that both isNotBlank and != null are sub-optimal! In a well-factored codebase you should strive to avoid both of them, but I tend to think that you should strive to avoid something like isNotBlank even more.

That said, how you check for null or the empty string is not terribly important. The JIT will almost certainly inline the checks anyway, and in many cases the peephole optimizer will elide them completely if it can prove null-safety another way. The far more important thing to consider is whether null is a valid value in your program, and if so, what it means semantically for a value to be null.

Answer 2

paymentTerm != null and StringUtils.isNotBlank(paymentTerm) don't perform the same thing.
If you want to only check the non nullity of a String object, you don't want to use isNotBlank() but use != null. So it may still make sense to use != null.
Note that as alternative you could also use Object.nonNull(Object) but it is often more verbose (but in a method reference where it makes completely sense : Object::nonNull).

After about whether we should test != "", != trimmed "" or just != null, it is a requirement matter.
Even if isNotBlank() includes != null, you will use it only as it is required because performing more checks that required is misleading code.

---

Here are simple examples where you can see that each way has a meaning and you have to use them (or no of them) in a way what makes their reading natural and pleasant.

1) You want to check the String length size.

if (myString != null && myString.length() == 8)

is what you need.
Doing it with isNotBlank() is verbose and conveys two very specific things (not blank and min length) while only the last one matters.

if (StringUtils.isNotBlank(myString) && myString.length() == 8)

2) You want to check that the String contain some characters.

if (myString != null && myString.contains("word"))

is still what you need.

if (String.isNotBlank(myString) && myString.contains("word"))  

Doing it with isNotBlank() appears still as noise.

3) You want to check the String equal to another one that cannot be null or that is a compile-time constant expression.

You want to directly write :

if ("word".equals(myString))

4) So when do you want to use isNotBlank() ?
Only when you need to check that a String is not null and doesn't contain only whitespaces (" ") characters.

if (StringUtils.isNotBlank("word"))

Answer 3

Your question is valid, but you could be more polite in the way you ask it.

The answer is, it depends. StringUtils offers a lot of nice methods. isNotBlank() checks for null, empty, and one or more blanks, and it saves a certain amount of manual checking. It can also simplify unit testing. On the other hand, your shop may not want to import and rely on an external library.

Generally, the right way, especially when you are starting out, is the same way. Politely ask the technical lead for their opinion, and go with it.