What is the difference between false and Boolean.FALSE?

Question 1

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.

Question 2

false is a primitive and Boolean.FALSE is an object, so they're not really comparable.

If you assign false to a Boolean variable, like this:

Boolean b = false;

Java's auto boxing occurs to convert the primitive into an object, so the false value is lost and you end up with Boolean.FALSE anyway.

In terms of performance, using a primitive variable would slightly out-perform using a wrapper Boolean object, but your choice should be based on readability and basic design decisions rather than on "performance".

Question 3

Boolean comes in handy when you need a tri-state variable.

Also, you might want to check out this autoboxing and unboxing tutorial, as well as the rules for how it works.

Question 4

It is a very strange question, because false is the value of primitive type boolean, while Boolean.FALSE is a variable of reference type Boolean. Its value is reference to the object of type Boolean which internal boolean state is false.

Question 5

In regards to performance, Boolean.FALSE will return a Boolean object, which might give you more flexibility to work with.

The primitive alternative takes up less memory

Question 6

First of all, if you are unclear with this, you need to know that in Java numericals cannot be implicitly cast to booleans, e.g. you cannot compile something like:

int a = 1;
if(a){
    //something, something
}

Second, some considerations about performance. There's always a tradeoff.

When using primitive type boolean, performance should be better because you're using a value directly, which is either true or false (obviously, byte-encoded).

When using object type Boolean, a variable/field will hold a value, but that value cannot be immediately used, as that value is in fact the reference to an object, so you might have a performance penalty. Of course, this penalty is not significant in most cases. And, if you develop a time-critical application, most likely you are not using Java :). Nevertheless, using object types might bring some benefits in development process and safety in use cases implementation (e.g. it allows nulls, which is critical when you map JPA entities to relational tables and there are bit-typed columns that allow nulls; and this is only one scenario where object type is better).

In the end, be aware of boxing/un-boxing, which allows developers to use boolean-typed variables almost everywhere a Boolean-typed variable is expected (and the other way around).

Question 7

Boolean is wrapper class for boolean primitive type, same as we have Integer for int.

Boolean has many methods to play around primitive type boolean

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

Question 8

Boolean a = null;
if (a) {
   // NullPointerException
}
if (a != false) {
   // NullPointerException
}
// Caution, comparing by reference, meaning 2 Booleans with same value could be different
if (a != Boolean.FALSE) {
    System.out.println("But this one works"); 
}