Boolean VS Boolean in Java

Boolean vs boolean in Java

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} The second will save you a lot more memory, so go for it

Now choose your way.

Differences among various bool types?

bool does not seem to exist, at least I can't find references to it.

boolean is a primitive boolean type, not an object.

Boolean is the wrapper object for a boolean.

What's the difference between boolean and Boolean in Java?

I'm not sure if the GWT factor makes a difference but in general:

boolean is a java primitive type whereas Boolean is an object/reference type that wraps a boolean

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

Here is more info:

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

Why box you ask?

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?

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.

Boolean vs boolean(s) as trilean switches

Best yet, use an type (probably an enum) with accurate descriptions of the three states. Booleans don't give a lot of information to the person who is calling the function (especially when used as a tristate).

public enum ActiveStatus {
  On,
  Off,
  Unknown
}

What is the difference between false and Boolean.FALSE?

See http://docs.oracle.com/javase/7/docs/api/java/lang/Boolean.html.

Boolean.TRUE and Boolean.FALSE are not boolean, they are Boolean. They are static instances of the two Boolean wrapper objects that correspond to the boolean values true and false.

Boolean is similar to an enum. The TRUE and FALSE instances are the instances returned by Boolean.valueOf().

As for performance of primitive vs. wrapper; there is no difference that you would ever need to be concerned about. The TRUE and FALSE static instances help performance a bit, and the javadocs recommend using Boolean.valueOf() as opposed to new Boolean(...) for that reason. The true and false boolean values are a little "lower level", but if you are storing them in a Boolean (as opposed to boolean) anyways it's irrelevant.

You should use whichever makes the most sense for your code and leads to the best readability (and definitely don't start going down the path of thinking of microoptimizations like primitive vs. wrapper types). If you are using a Boolean, use the object values. If you are using a boolean, use the primitive values. If you are deciding between Boolean vs boolean, use whatever is more appropriate (e.g. a Boolean can be null, which may be useful, and also you can't use primitive types for generic type parameters; on the other hand, a boolean can never be null which could be equally useful).

Also note that auto boxing converts the primitive types to one of those two static Boolean instances, e.g.:

Boolean a = true;
assert(a == Boolean.TRUE);

As an aside, since you mentioned it: FALSE is defined in windows.h for two reasons: 1) Because windows.h has been in use since C-only days, and C does not have a native bool type, and 2) it is traditional Microsoft practice to define data types and values with known, explicit sizes and values, esp. for passing data to Windows API functions across DLL boundaries (beyond the scope of this question) and for integrating with other languages that have different representations of "true" and "false". It is entirely unrelated to the reasons for Boolean.FALSE in Java.

Is it better to assign Boolean.TRUE/Boolean.FALSE or true/false to a boolean primitive variable?

You are right that the performance concerns are mostly a distraction.

To understand what is going on, let's look at how primitives and their boxes are modeled in the Java type system.

When C extends D, this means that a C is-a D, or that C is a subtype of D. When assigning an Integer to Number, no conversion is required, because an Integer is-a Number. Under the hood, both Integer and Number are represented by pointers (object references) and the assignment is just a pointer copy.

The relationship between boolean and Boolean is different, though. There is no extends; there is no is-a. Instead, there are boxing and unboxing conversions, which get applied in certain contexts (e.g., assignment, method parameters.) Their representations are different. So when you convert between boolean and Boolean, the form changes (from a direct representation of the boolean value, to a pointer to a heap node containing an object header and a boolean payload.) This is why people warn you about "the performance cost"; it's not just copying one word. (That said, if this is the performance bottleneck in your program, you've got bigger problems -- namely that your program doesn't do very much.)

When you assign

boolean b = true;

Boolean bb = Boolean.TRUE;

the types on both sides of the = are the same -- boolean in the first example, Boolean in the second -- and there is no conversion. When you do

boolean b = Boolean.TRUE;

Boolean bb = true;

the types are different, and there is a conversion required. The compiler silently translates these to:

boolean b = Boolean.TRUE.booleanValue();

and

Boolean bb = Boolean.valueOf(true);

In the specific case of boolean, the performance concerns are even less relevant than for other primitives, since there are only two boolean values, and the constants Boolean.TRUE and Boolean.FALSE are interned.

If your architect gave you this advice primarily on performance concerns, then he/she was misguided. If their advice was motivated more by simplicity -- that it is equally easy to use a value of the correct type that requires no conversion -- this is sensible.

Boolean and == vs =

if (identifier = literal) evaluates to:

identifier = literal;  
if (identifier)

first you assign the literal to the identifier. then you test it post assignment

Java trie node Boolean vs boolean

Instead of this:

boolean EOW = Boolean.TRUE;

Just write this:

boolean EOW = true;

There is no reason to use Boolean.TRUE, it will be auto-unboxed to the primitive value true anyway, it's more efficient and less verbose to use the value true directly.

Only use wrapper classes such as Boolean when you have a good reason to do so - otherwise, use primitive types such as boolean. One reason to use a wrapper is when you need to store values in a collection (such as an ArrayList) - collection classes can only hold objects and not primitive values, so you'll have to use the wrapper class in that case.

Using Boolean objects is never more efficient than using boolean primitive values.

Note that primitive values are just values, not objects. If you use the value true ten times in your code, there will not be ten duplicate objects in memory.

Boolean VS Boolean in Java