When should I use Boolean instead of boolean?

Question

When should I use Boolean instead of boolean?. I mean, why would I want to have a null value in a variable which should contain either "true" or "false".. One spontaneous answer (of most people) would be if the value is unknown. i.e, if we don't know whether the value is true or false. But from a programming perspective, I think using Boolean may break the code as we will not know whats inside. So, I think using the primitive type is better than the wrapper.. Correct me if I am wrong.

I disagree with the duplicate close; that question is misnamed and is asking more about `boolean` vs. `int`. — chrylis -cautiouslyoptimistic-, Sep 23 '13 at 06:56
(Another) Answer to this one: https://stackoverflow.com/a/53705497/6931119 Could not answer against this post. — Witold Kaczurba, Dec 10 '18 at 12:18

chrylis -cautiouslyoptimistic- · Accepted Answer · 2019-08-06T17:53:51.253

Generally speaking, the wrapper classes are used in cases where an object is required or strongly preferred. Outside of these situations, it's better to use the primitive types, since they have lower overhead, you can use ==, etc. There are two and a half major situations where this is frequently seen:

Collections. This is now a subset of the next case, but even before Java 5 the Collections classes only supported objects as keys and values, and this hasn't changed.
Generics. Generic types can only work with objects, not primitives, and so if you're using "boolean" as a type parameter, it has to be the wrapper class. For example, if you're using a Future, you have to use a Boolean instead of a boolean. (HT @user949300)
ORM. JPA and other ORM systems technically can use primitive fields, but it's customary to use the wrapper classes, since the overhead is high enough that that doesn't really matter anyway, and the wrapper classes can represent a NULL value that might be present in the database. It's usually still better to forbid nulls and use a primitive for booleans, though, since semantically a default is usually better than "undefined".

Since boolean values are restricted to either true or false, it's uncommon to see them used in Collections or Generics; generally speaking, if you'd have a boolean as a value, you'll just use Collection#contains instead.

+1 Good point on the Generics. Example if a long running process (Future) needs to return a true/false, it must return a Boolean, not a boolean. — user949300, Sep 23 '13 at 07:00

Suresh Atta · Answer 2 · 2013-09-23T07:06:57.873

11

IMHO the primitive is better.

Always favor primitives over wrappers. Wherever I am able to use primitives, I go for them because at run time, if we use wrappers, boxing conversions and unboxing conversions happen, and obviously that takes more time. If you use the primitive there, you save that time.

And as usual it depends on your requirements whether you need a Object (which can be null) or you can use a primitive (which cannot be null) in your situation.

For example: Assume you are dealing with collection's then you have no option's,You have to use wrappers :).

edited Sep 23 '13 at 07:06

answered Sep 23 '13 at 06:51

Suresh Atta

120,458
37
198
307

1

What if you need `null`? That should be the only consideration. "Saving time or memory" is a non-issue with Boolean, which only has two static instances that are already created before your program even starts running. – Thilo Sep 23 '13 at 06:54
@Thilo True. That is why I used the term Object which can be `null`. – Suresh Atta Sep 23 '13 at 06:55
1

Agree with @Thilo. While there are good reasons for preferring primitives over wrappers, performance is seldom an issue, especially with Booleans. Don't understand why this answer is getting all the votes. – user949300 Sep 23 '13 at 07:07
@user949300 No issues,I pointed why to go for primitives and as well as when to go for wrappers.Please feel free to down vote if you are not satisfied with this,I'm with you. :) – Suresh Atta Sep 23 '13 at 07:11
The program I have written is something like this... if(boolean_val) do {something} , else { do someOtherThing.. }.. Now, to add boolean values to collections, I changed them to Boolean, now, the problem is I have 3 cases (true, false and null) and I have to handle the "null" case as well.. And I feel it makes no sense to check for null values.. imagine having hundreds of Boolean values and adding lines like if(val is null) – TheLostMind Sep 23 '13 at 07:20
@X86 Then write a small util method.Such that that method takes takes a collection object and Boolean object as parameters.There check null/or any conditions there and add to that collection.So you should not duplicate your code. – Suresh Atta Sep 23 '13 at 07:22
@X86 Don't write those utility methods. Use Commons-Lang [`BooleanUtils`](http://commons.apache.org/proper/commons-lang/apidocs/src-html/org/apache/commons/lang3/BooleanUtils.html#line.32) instead. ;-) – chrylis -cautiouslyoptimistic- Sep 23 '13 at 07:34

score 5 · Answer 3 · answered Sep 23 '13 at 06:51

5

Boolean have 3 possible values (null, true, false) while boolean can only be (true, false).

answered Sep 23 '13 at 06:51

AppX

528
2
12

score 3 · Answer 4 · answered Sep 23 '13 at 06:55

I greatly prefer primitives. However, Booleans are necessary:

When they go into Collections
When you need to allow for a null value. In my experience, this is mainly if they are stored in a database and you need null to indicate that they haven't been read yet, or the user hasn't filled in some form yet.

score 0 · Answer 5 · answered Sep 23 '13 at 06:51

What if you need to use collections? Collection will not store primitive types, you need to store object there. Collections provide so many utility apis, so if you want to use them them a Boolean object is need as collection will need objects. Although you can always use autoboxing which means you are shielded from object creation and collection takes care of it internally.

score 0 · Answer 6 · edited May 23 '17 at 11:54

0

The Wrapper classes will be in cases where an object is required or strongly preferred like storing the objects in Collections, cache or session etc, where it requires an object (if not, JRE will convert the primitives to Wrapper classes before they are stored in secondary cache). The below link will explain in better:

Boolean vs boolean in Java

edited May 23 '17 at 11:54

Community

1
1

answered Sep 23 '13 at 06:51

Raghavendra Reddy Busireddy

485
3
9

score 0 · Answer 7 · answered Sep 23 '13 at 06:54

Boolean is an object, so you can use it with generics. For example, you can have Map<String,Boolean> to store a true\false value for each string(=key). You can't do Map<String,boolean>, because boolean is not an object - specifically, it's not a subclass of Object. Generics are compile-time wrappers, so Map<Foo,Bar> is actually Map<Object,Object> with smart casting, no matter what Foo and Bar are - as long as they are classes or array types. But they can't be primitives.

score 0 · Answer 8 · answered Sep 23 '13 at 06:58

Booolean is an object/reference type that wraps a boolean whereas boolean in a primitive type.

Boolean - You would get more methods which will be useful.

boolean - Will save you lot of memory. But if you use Boolean.valueOf(value) of new Boolean(value), that shouldn't be a cause.

Converting between primitives and objects like this is known as boxing/unboxing.

Click on the below links for more info:

http://javaeye.wordpress.com/2008/06/17/boxing-and-unboxing-conversion/

http://java.sun.com/j2se/1.5.0/docs/guide/language/autoboxing.html

http://www.javapractices.com/topic/TopicAction.do?Id=197

When should I use Boolean instead of boolean?

8 Answers8

Linked