Take the 2-minute tour ×

There are discussion around Integer vs int in Java. The default value of the former is null while in the later it's 0. How about Boolean vs boolean?

A variable in my application can have 0/1 values. I would like to use boolean/Boolean and prefer not to use int. Can I use Boolean/boolean instead?


share|improve this question
For system design reasons I would choose Boolean since it has the option "The user didn't decide yet" which is neither equals with "true", nor "false". I would use boolean primitive only in cases if I am 100% sure true/false options are enough. In database NULL option is usually available without problem (or by just removing NOT NULL restrictions on later demand) –  CsBalazsHungary Dec 12 at 9:45

4 Answers 4

up vote 58 down vote accepted

yes you can use Boolean/boolean instead.

First one is Object and second one is primitive type

On first one, you will get more methods which will be useful

Second one is cheap considering memory expense.

Now choose your way

share|improve this answer
You could have phrased this as "the second will save you a lot more memory, so go for it". The useful methods on Boolean can mostly be invoked without having an instance of it. –  DJClayworth Sep 16 '10 at 16:29
@DJClayworth edited –  Jigar Joshi Sep 16 '10 at 16:34
As long as you use instead Boolean.valueOf(value) of new Boolean(value), memory shouldn't be a concern. –  Greg Case Sep 16 '10 at 18:22
for AsyncTask, you can only use Boolean instead of boolean. –  Raptor Jan 13 at 10:03
It should be noted the a Boolean actually has 3 states... true, false and null where a boolean has the logical 2 states (true and false) –  respectTheCode Jun 6 at 15:46

Boolean wraps the boolean primitive type. In JDK 5 and upwards, Oracle (or Sun before Oracle bought them) introduced autoboxing/unboxing, which essentially allows you to do this

boolean result = Boolean.TRUE;


Boolean result = true; 

Which essentially the compiler does,

Boolean result = Boolean.valueOf(true);

So, for your answer, it's YES.

share|improve this answer
Thanks for the hints! –  Neel Sep 16 '10 at 16:42

I am a bit extending provided answers (since so far they concentrate on their "own"/artificial terminology focusing on programming a particular language instead of taking care of the bigger picture behind the scene of creating the programming languages, in general, i.e. when things like type-safety vs. memory considerations make the difference):

int is not boolean


    boolean bar = true;      
    System.out.printf("Bar is %b\n", bar);
    System.out.printf("Bar is %d\n", (bar)?1:0);
    int baz = 1;       
    System.out.printf("Baz is %d\n", baz);
    System.out.printf("Baz is %b\n", baz);

with output

    Bar is true
    Bar is 1
    Baz is 1
    Baz is true

Java code on 3rd line (bar)?1:0 illustrates that bar (boolean) cannot be implicitly converted (casted) into an int. I am bringing this up not to illustrate the details of implementation behind JVM, but to point out that in terms of low level considerations (as memory size) one does have to prefer values over type safety. Especially if that type safety is not truly/fully used as in boolean types where checks are done in form of

if value \in {0,1} then cast to boolean type, otherwise throw an exception.

All just to state that {0,1} < {-2^31, .. , 2^31 -1}. Seems like an overkill, right? Type safety is truly important in user defined types, not in implicit casting of primitives (although last are included in the first).

Bytes are not types or bits

Note that in memory your variable from range of {0,1} will still occupy at least a byte or a word (xbits depending on the size of the register) unless specially taken care of (e.g. packed nicely in memory - 8 "boolean" bits into 1 byte - back and forth).

By preferring type safety (as in putting/wrapping value into a box of a particular type) over extra value packing (e.g. using bit shifts or arithmetic), one does effectively chooses writing less code over gaining more memory. (On the other hand one can always define a custom user type which will facilitate all the conversion not worth than Boolean).

keyword vs. type

Finally, your question is about comparing keyword vs. type. I believe it is important to explain why or how exactly you will get performance by using/preferring keywords ("marked" as primitive) over types (normal composite user-definable classes using another keyword class) or in other words

boolean foo = true;


Boolean foo = true;

The first "thing" (type) can not be extended (subclassed) and not without a reason. Effectively Java terminology of primitive and wrapping classes can be simply translated into inline value (a LITERAL or a constant that gets directly substituted by compiler whenever it is possible to infer the substitution or if not - still fallback into wrapping the value).

Optimization is achieved due to trivial:

"Less runtime casting operations => more speed."

That is why when the actual type inference is done it may (still) end up in instantiating of wrapping class with all the type information if necessary (or converting/casting into such).

So, the difference between boolean and Boolean is exactly in Compilation and Runtime (a bit far going but almost as instanceof vs. getClass()).

Finally, autoboxing is slower than primitives

Note the fact that Java can do autoboxing is just a "syntactic sugar". It does not speed up anything, just allows you to write less code. That's it. Casting and wrapping into type information container is still performed. For performance reasons choose arithmetics which will always skip extra housekeeping of creating class instances with type information to implement type safety. Lack of type safety is the price you pay to gain performance. For code with boolean-valued expressions type safety (when you write less and hence implicit code) would be critical e.g. for if-then-else flow controls.

share|improve this answer
Thanks for the detailed explanation, this is exactly the kind of detailed description that really helps make my choice easier. –  munkay May 6 at 4:22

You can use the Boolean constants - Boolean.TRUE and Boolean.FALSE instead of 0 and 1. You can create your variable as of type boolean if primitive is what you are after. This way you won't have to create new Boolean objects.

share|improve this answer

Your Answer


