Reputation: 959
I see that the explicit cast syntax for boolean (boolean)
is syntactically legal, but I can't think of a use for it. The corresponding Boolean object -- or rather casting back and forth between boolean and Boolean -- is handled by autoboxing. So it seems like a useless language artifact of the compiler. Is there a functional scenario I am missing?
Upvotes: 64
Views: 7463
Reputation: 20185
It can make a difference when an overloaded method is called. Since the method to call is determined by the static type(s) of the parameter(s) (See JLS, §15.12.2), casting a Boolean
to a boolean
or vice-versa can change which method is called:
class Ideone {
public static void main (String[] args) {
final Boolean b = true;
foo((boolean) b); // prints out "primitive"
foo(b); // prints out "wrapper"
}
public static void foo(boolean b) {
System.out.println("primitive");
}
public static void foo(Boolean b) {
System.out.println("wrapper");
}
}
Notice that when casting from Boolean
to boolean
, a NullPointerException
may occur when the Boolean
has a value of null
.
Whether this behaviour is (extensively) used or should be used is another debate, however.
rzwitserloot showed another case with boolean
and Object
in their answer. While rzwisterloot's case seems similar, the underlying mechanism is different since the downcast from Object
to boolean
is defined separately in the JLS. Furthermore, it is prone to a ClassCastException
(if the Object
is not a Boolean
) aswell as a NullPointerException
(if the Object
is null
).
Upvotes: 102
Reputation: 298233
As stated in other answers, you can use a cast to boolean
to enforce auto-unboxing or to select from overloaded methods. As a special case, calling invokeExact
on MethodHandle
may require such a cast to select the right method signature, even for the return type.
But there was a time when neither of these features existed, still, a boolean
cast was allowed. Adding a special rule for boolean
would not make the language simpler. But the implications of allowing this feature had been considered.
When we look into second edition of the language specification:
5.1.1 Identity Conversions
A conversion from a type to that same type is permitted for any type. This may seem trivial, but it has two practical consequences. First, it is always permitted for an expression to have the desired type to begin with, thus allowing the simply stated rule that every expression is subject to conversion, if only a trivial identity conversion. Second, it implies that it is permitted for a program to include redundant cast operators for the sake of clarity.
The only permitted conversion that involves the type boolean is the identity conversion from
boolean
toboolean
.
So back then, a boolean
value could only be cast to boolean
, that was even stated explicitly, but was intentionally allowed, e.g. “for the sake of clarity”.
Consider a call like foo(bar())
vs. foo((boolean)bar())
.
Or, stringBuffer.append((boolean)someMethod())
.
The cast could not alter the behavior of the program but provide additional information to the human reader.
Today’s version still states that identity conversions are allowed, but does not restrict the conversions of boolean
to identity conversion, as we now can convert between boolean
and reference types.
There’s even a second mentioning in the old version:
15.16 Cast Expressions
A cast expression converts, at run time, a value of one numeric type to a similar value of another numeric type; or confirms, at compile time, that the type of an expression is boolean; or checks, at run time, that a reference value refers to an object whose class is compatible with a specified reference type.
Since conversions between primitive types and reference types were not possible back then, there were three distinct use cases for casts, numeric conversions, reference type changes, or it “confirms, at compile time, that the type of an expression is boolean”.
As that’s the only thing a boolean
cast could do in that Java version.
Upvotes: 14
Reputation: 103018
Not entirely.
Ordinarily, applying the cast operator with a primitive type serves only one purpose, which is to convert one primitive type to another. boolean
is the only primitive type with the property that nothing can be converted to a boolean, and a boolean cannot be converted to anything else.
But, there is a second purpose to these, although it's not exactly spelled out in the JLS and is a dubious code style practice: It effectively causes auto-unboxing to trigger. And it even combines the job of triggering auto-unbox and an ordinary type cast:
Object o = true;
boolean b = (boolean) o;
o = "Hello";
b = (boolean) o;
compiles just fine. It'll cause a ClassCastException on the 4th line, as expected. Without the boolean cast, you'd have to do something like:
boolean b = ((Boolean) o).booleanValue();
which is definitely more wordy. Exactly how often you end up wanting to cast some expression of type Object
to boolean
- probably that's a very rare occurrence, but it is a real one, and disallowing (boolean)
would have made the JLS longer, not shorter (and the javac codebase wouldn't be any shorter either).
Upvotes: 26