Hi,
A co-worker asked me to change a signature from using a primitive "boolean" to using a classed "Boolean". He didn't offer a very good explanation why?
Have any of you heard of this and can any of you explain why it matters or doesn't matter?
Edit: He mentioned that it was good practice for public methods.
The use of the field is just a flag that tells me whether to call one flow or another depending on whether it's true or false.
Actually I tend to err on the side of passing small-b boolean instead, because I know that a primitive boolean is never going to be null. I'm sure there are valid reasons for using the Boolean type, but I'd want to think about its use in each case.
Is it database-related? If you have a boolean value in a database, it can hold one of THREE values -- true, false, and null. The Boolean object would let you mimic that behavior.
Basically, it's a matter of whether you want to deal with "null" as a potential input value.
Actually, in general, it's good practice to use regular primitives unless there's a specific reason not to. It will be slightly faster/less wasteful, though you'd need to be moving a lot of objects around for that to really matter.
In response to your edit, I've never heard of it being good practice for public methods. In the often-cited Effective Java by Josh Bloch, there's an entire item "Prefer primitive types to boxed primitives" (item 49, if you can get your hands on a copy). It sounds like your specific case has no reason to favor of using a big-b Boolean, and using objects creates pitfalls like poor interaction with old code that, for example, uses == rather than equals() (which isn't even possible for a primitive).
I typically try to make use of the primitive boolean wherever possible.
The only possibility that I can think for a developer to want the Boolean class is boxing/unboxing (but I would think you'd want to prevent boxing/unboxing whenever possible rather than encourage it everywhere) and the possibility for null values.
If you control both sides of the interface (i.e. the calling code and the called method) then you should simply be consistent. You actually incur a bit of overhead if you force the compiler to autobox the variable for you.
If the method in question is one of a set of methods with similar signatures, and all others pass an object of some kind in the position where your boolean goes, then using an object rather than a primitive might simply be a matter of being a bit more consistent.
EDIT: Re-reading the question, if that boolean parameter is really just there to control an if (which is exactly what the primitive is there for), then using the object form is simply a waste of CPU time and memory. I can't think of a sensible reason why it should be an object rather than a primitive.
The main advantage of Boolean over primitive booleans is that they allow you to have a null value. This is particularly effective for return values but can sometimes be used for an "optional" argument in Java.
Make sure your JavaDocs (and code) can deal with the null
Never heard of any valid reason to prefer Boolean over boolean.
Given a chance, always stick with primitives. Boolean variables can be null; and thus can introduce an unexpected behavior in your method. Your co-worker may have some specific reasons based on program implementation/logic.
If you use Boolean, then you can either pass a boolean or a Boolean to the method
public void setX(boolean b) //only takes boolean
public void setX(Boolean b) //takes Boolean or boolean
This is due to the autoboxing of the booleans into the function.
EDIT: The autoboxing only works in 1.5+
Keep it simple. Using Boolean:
Are you using any kind of data-binding framework in your app? I recently had to deal with a case where a boolean in a model object needed to be bound to a form. The field in the form was required, but we didn't want to default the value to true or false (because it was important for the user to choose the correct value for the specific case, if there was a default, you'd easily get a lot of incorrect values.) However, before the object could be validated, values from the form had to be bound to it. Of course, if the user hadn't selected a value, it would attempt to bind null to the field, and an exception would be thrown during the bind. So we changed it to a Boolean so that null could be bound to the field temporarily, and then validation could report that the field was required.