Is there a valid reason to code a false boolean as "Boolean.FALSE" in java?

So code 开发者_JS百科reviewers are complaining about code like this:

boolean myFlag = false;

They are saying it should be:

boolean myFlag = Boolean.FALSE;

Is this just some fetish with not using keywords or is there a valid reason to do this?

---

No, that's completely pointless. It would make sense to use:

// Note capital B
Boolean myFlag = Boolean.FALSE;

to avoid the call to Boolean.valueOf (autoboxing) but in your code there is no boxing, and their suggestion introduces an unnecessary unboxing operation.

As ever though, if someone suggests something and you don't understand why, your first port of call should be asking them.

---

There's nothing wrong with using keyword false. In fact, in your code you'd be silly to use Boolean.False since there is an implicit auto unboxing that has to occur to assign it to your primitive field/variable (Boolean.False is a Boolean and not a boolean).

---

It doesn't make much sense as a complaint since Boolean.FALSE is unboxed to false anyway. But perhaps ask the people telling you to change the code why?

---

I can only think of one reason, if you really want to dig for a possible reason:

In an IDE like Eclipse, you can right-click FALSE (in Boolean.FALSE) and select Open Call Hierarchy or References > (option). You can't do that with the literal false. But I don't know how useful finding all references of Boolean.FALSE will be in your development cycles.

Curiously, when I searched for references of FALSE, it was found littered all over the Java core (JDK/JRE) source code! Whether we want to use it or not, one thing is for sure, the guys who coded and maintain Java are using it heavily.

As per other answers, it's otherwise unnecessary and you can just use the literal false, especially if performance is important - avoiding the unboxing overhead. Code reviews must prioritize optimized readable/adequately-commented code over unoptimized readable code.