35

I've come across this code in one of the projects I'm working on

(This is in Java)

if (Boolean.TRUE.equals(foo.isBar()))

Foo#isBar() is defined as boolean isBar(), so it can't return null

Is there really any reason why it should be written that way? I myself would just write

if (foo.isBar())

, but perhaps I'm missing something subtle.

Thanks

user1508893
  • 9,223
  • 14
  • 45
  • 57

5 Answers5

40

I hope foo.isBar() returns a boolean. In that case you can always write if (foo.isBar()). If you foo.isBar() returns Boolean then it can be either Boolean.TRUE, Boolean.FALSE or NULL. In that case if (Boolean.TRUE.equals(foo.isBar())) makes sure the if block is executed in one scenario(TRUE) and omitted in remaining 2.

Over and above if (foo.isBar()) will fail, when foo.isBar() returns Boolean NULL.

Yogendra Singh
  • 33,927
  • 6
  • 63
  • 73
  • So what will Boolean.TRUE.equals(foo.isBar()) return if foo.isBar() return null? Would it convert null to false or would it allow the boolean to be null? – TheLearner Oct 27 '17 at 21:54
  • 5
    `Boolean.TRUE.equals(null)` evaluates to `false`. – Antillean Oct 10 '18 at 16:46
  • 1
    Be careful with Boolean object, Boolean.FALSE.equals(null) is false but it does not mean it's true. !Boolean.TRUE.equals(var) is not the same as Boolean.FALSE.equals(var) because of the null posibility. – Martin P. Feb 22 '23 at 13:51
26

Since isBar returns a primitive boolean, there is no semantic difference. Additionally, the second way is more concise, more clear, and more efficient, since the result won't have to be autboxed for the call and then have the original boolean extracted again. Given all that, there is no reason to use the first method, and several to use the second, so use the second. I give a great deal of leeway to fellow coders, but I would sit down and have a chat with anyone who added something like that to professional code.

Kevin
  • 53,822
  • 15
  • 101
  • 132
  • 2
    +1 Is similar to `if (true == foo.isBar())` or `if (isTrue(foo.isBar()))` They are needlessly verbose. I am not sure why some people prefer this. Perhaps some people prefer something which read more like English and find this reassuring. – Peter Lawrey Oct 08 '12 at 06:22
7

I would suspect "old legacy code with no good reason" - and in fact, I would contend it is worse. (I wonder how ints are compared ..)

The code that uses TRUE.equals requires a boxing conversion, an additional method call (and everything inside) and, in the end, it just looks sloppy.

The only reason I am aware of is if foo.isBar was typed as returning Boolean (not boolean) and where it may return null:

Boolean b = null;

// throws an exception when it tries to unbox b because it is null
boolean isTrue1 = (boolean)b;

// evaluates to false
boolean isTrue2 = Boolean.TRUE.equals(b);

// evaluates to false as well
boolean isTrue3 = b != null ? (boolean)b : false;
0

Did I find this practical example, can be useful to someone:

When boxed type java.lang.Boolean is used as an expression it will throw NullPointerException if the value is null as defined in Java Language Specification §5.1.8 Unboxing Conversion.

It is safer to avoid such conversion altogether and handle the null value explicitly.

Noncompliant Code Example

Boolean b = getBoolean();
if (b) {  // Noncompliant, it will throw NPE when b == null
  foo();
} else {
  bar();
}

Compliant Solution

Boolean b = getBoolean();
if (Boolean.TRUE.equals(b)) {
  foo();
} else {
  bar();  // will be invoked for both b == false and b == null
}
The Doctor
  • 1
  • 1
-3

in the first condition you are checking for the equality of Boolean object corresponding to true. and you are using the first condition in your code because your java version doesn't support autounboxing hence you need to use the boolean object.

What is the difference between Boolean.TRUE and true in Java?

Community
  • 1
  • 1
rbhawsar
  • 805
  • 7
  • 25