When should null values of Boolean be used?

Question

Use boolean rather than Boolean every time you can. This will avoid many NullPointerExceptions and make your code more robust.

Boolean is useful, for example

• to store booleans in a collection (List, Map, etc.)
• to represent a nullable boolean (coming from a nullable boolean column in a database, for example). The null value might mean "we don't know if it's true or false" in this context.
• each time a method needs an Object as argument, and you need to pass a boolean value. For example, when using reflection or methods like MessageFormat.format().

I almost never use Boolean because its semantics are vague and obscure. Basically you have 3-state logic: true, false or unknown. Sometimes it is useful to use it when e.g. you gave user a choice between two values and the user didn't answer at all and you really want to know that information (think: NULLable database column).

I see no reason to convert from boolean to Boolean as it introduces extra memory overhead, NPE possibility and less typing. Typically I use awkward BooleanUtils.isTrue() to make my life a little bit easier with Boolean.

The only reason for the existence of Boolean is the ability to have collections of Boolean type (generics do not allow boolean, as well as all other primitives).

Wow, what on earth? Is it just me or are all these answers wrong or at least misleading?

The Boolean class is a wrapper around the boolean primitive type. The use of this wrapper is to be able to pass a boolean in a method that accepts an object or generic. Ie vector.

A Boolean object can NEVER have a value of null. If your reference to a Boolean is null, it simply means that your Boolean was never created.

You might find this useful: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/lang/Boolean.java

A null Boolean reference should only be used to trigger similar logic to which you have any other null reference. Using it for three state logic is clumsy.

EDIT: notice, that Boolean a = true; is a misleading statement. This really equals something closer to Boolean a = new Boolean(true); Please see autoboxing here: http://en.wikipedia.org/wiki/Boxing_%28computer_science%29#Autoboxing

Perhaps this is where much of the confusion comes from.

EDIT2: Please read comments below. If anyone has an idea of how to restructure my answer to incorporate this, please do so.

There are three quick reasons:

• to represent Database boolean values, which may be true, false or null
• to represent XML Schema's xsd:boolean values declared with xsd:nillable="true"
• to be able to use generic types: List<Boolean> - you can't use List<boolean>

ANSWER TO OWN QUESTION: I thought it would be useful to answer my own question as I have learnt a lot from the answers. This answer is intended to help those - like me - who do not have a complete understanding of the issues. If I use incorrect language please correct me.

• The null "value" is not a value and is fundamentally different from true and false. It is the absence of a pointer to objects. Therefore to think that Boolean is 3-valued is fundamentally wrong

• The syntax for Boolean is abbreviated and conceals the fact that the reference points to Objects:

  Boolean a = true;

conceals the fact that true is an object. Other equivalent assignments might be:

Boolean a = Boolean.TRUE;

or

Boolean a = new Boolean(true);

• The abbreviated syntax

  if (a) ...

is different from most other assignments and conceals the fact that a might be an object reference or a primitive. If an object it is necessary to test for null to avoid NPE. For me it is psychologically easier to remember this if there is an equality test:

if (a == true) ...

where we might be prompted to test for null. So the shortened form is only safe when a is a primitive.

For myself I now have the recommendations:

• Never use null for a 3-valued logic. Only use true and false.
• NEVER return Boolean from a method as it could be null. Only return boolean.
• Only use Boolean for wrapping elements in containers, or arguments to methods where objects are required

Wrapper classes for primitives can be used where objects are required, collections are a good sample.

Imagine you need for some reason store a sequence of boolean in an ArrayList, this can be done by boxing boolean in Boolean.

There is a few words about this here

From documentation:

As any Java programmer knows, you can’t put an int (or other primitive value) into a collection. Collections can only hold object references, so you have to box primitive values into the appropriate wrapper class (which is Integer in the case of int). When you take the object out of the collection, you get the Integer that you put in; if you need an int, you must unbox the Integer using the intValue method. All of this boxing and unboxing is a pain, and clutters up your code. The autoboxing and unboxing feature automates the process, eliminating the pain and the clutter.

http://docs.oracle.com/javase/1.5.0/docs/guide/language/autoboxing.html

Boolean wrapper is useful when you want to whether value was assigned or not apart from true and false. It has the following three states:

• True
• False
• Not defined which is null

Whereas boolean has only two states:

• True
• False

The above difference will make it helpful in Lists of Boolean values, which can have True, False or Null.