StringUtils.isBlank() checks that each character of the string is a whitespace character (or that the string is empty or that it's null). This is totally different than just checking if the string is empty.

From the linked documentation:

Checks if a String is whitespace, empty ("") or null.

 StringUtils.isBlank(null)      = true
 StringUtils.isBlank("")        = true  
 StringUtils.isBlank(" ")       = true  
 StringUtils.isBlank("bob")     = false  
 StringUtils.isBlank("  bob  ") = false

For comparison StringUtils.isEmpty:

 StringUtils.isEmpty(null)      = true
 StringUtils.isEmpty("")        = true  
 StringUtils.isEmpty(" ")       = false  
 StringUtils.isEmpty("bob")     = false  
 StringUtils.isEmpty("  bob  ") = false

Warning: In java.lang.String.isBlank() and java.lang.String.isEmpty() work the same except they don't return true for null.

java.lang.String.isBlank() (since Java 11)

java.lang.String.isEmpty()

No, absolutely not - because if acct is null, it won't even get to isEmpty... it will immediately throw a NullPointerException.

Your test should be:

if (acct != null && !acct.isEmpty())

Note the use of && here, rather than your || in the previous code; also note how in your previous code, your conditions were wrong anyway - even with && you would only have entered the if body if acct was an empty string.

Alternatively, using Guava:

if (!Strings.isNullOrEmpty(acct))

Correct way to check for null or empty or string containing only spaces is like this:

if(str != null && !str.trim().isEmpty()) { /* do your stuffs here */ }

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.