Initialization of a boolean with a Boolean.FALSE/.TRUE - why?

Question

In some of our companys projects code I often read something like this:

boolean foo = Boolean.FALSE;

Besides the fact that AFAIK I only have to initialize local variables in Java at all (no random values like in Pascal) and besides the fact that especially for booleans I often WANT to have an initialization, what do I miss here? Why not:

boolean foo = false;

I don't get it. And code analyzation tools like PMD and Findbugs mark it, too. But why?

Edit: Without really knowing much about the bytecode except that it is there I created an example class and decompiled it. The Boolean.FALSE went to:

0: getstatic #15 // Field java/lang/Boolean.FALSE:Ljava/lang/Boolean; 
3: invokevirtual #21 // Method java/lang/Boolean.booleanValue:()Z 
6: istore_1 

The 'false' variant went to:

0: iconst_1 
1: istore_1 

So without knowing too much about this, I'd guess that more statements means more time to execute so it's not only wrong but also slower in the long run.

Answer 1

boolean foo = Boolean.FALSE;

This is strange and unnecessarily complicated code, written by someone who likely didn't know Java very well. You shouldn't write code like this, and PMD and FindBugs are right to mark this.

Boolean.FALSE is a java.lang.Boolean object that gets auto-unboxed; the compiler essentially translates this to:

boolean foo = Boolean.FALSE.booleanValue();

I don't have to initialize variables in Java at all...

Member variables do not need to be initialized explicitly; if you don't, they'll be initialized with a default value (which is false in the case of boolean ). Local variables do need to be explicitly initialized; if you try to use a local variable without initializing it, the compiler will give you an error.

Answer 2

Both are same. but boolean foo = false; is enough.

Answer 3

The style to use an auto-unboxed Boolean constant in fact meshes well with the overall oververbosity endemic to many Java projects. For example:

public boolean isItOrIsItNotTheValueWeExpect(String aStringParameterThatCouldBeNull) {
  boolean booleanReturnValue = Boolean.FALSE;
  if (aStringParameterThatCouldBeNull != null) {
    if (aStringParameterThatCouldBeNull.length() > 3) {
      booleanReturnValue = Boolean.TRUE;
    }
    else {
      booleanReturnValue = Boolean.FALSE;
    }
  }
  else if (aStringParameterThatCouldBeNull == null) {
    booleanReturnValue = Boolean.TRUE.booleanValue();
  }
  return booleanReturnValue;
}

Obviously, the code above would be much preferred to this unreadable mess:

public boolean validate(String s) {
  return s == null? true : s.length() > 3;
}

The very occurrence of a ternary operator is considered a transgression and some projects even have it flagged by CheckStyle.

If your projects conform to such stylistic guidelines as these, that could justify your suspicious line of code.

Answer 4

There is no good reason to do this, it was probably just a novice Java programmer. I wouldn't worry too much, just replace it with false.

At the same time, you can usually if not always arrange your code such that you never declare a variable you don't have the final value for, ie, making your objects immutable, which makes them easier to think about. What's the value of x? compared to What's the value of x between the calls to foo() and bar()? The first is generally easier to answer. This requires you to split up your classes along lines you might not be used to doing but I recommend at least trying it out.

Answer 5

There is no difference really although the 1st method won't work on a 1.4 or earlier JVM. The first is more convoluted since it is fetching the static value from the Boolean object and then relying on autoboxing (introduced in 1.5) to change it from a Boolean object to a boolean primitive) although I can't imagine it would ever make any speed difference.

Generally though if you are assuming a particular initial value for a variable then I would recommend initialising it rather than just declaring it as it makes the code more readable.