On 3/16/2010 6:56 PM, Arne Vajh?j wrote:
On 12-03-2010 20:52, Daniel Pitts wrote:
On 3/12/2010 5:29 PM, Arne Vajh?j wrote:
On 12-03-2010 11:25, Daniel Pitts wrote:
On 3/12/2010 6:02 AM, angelochen960@gmail.com wrote:
I have this bean:
public class Item {
private String type;
private Boolean pub;
This should probably be a "boolean", not a Boolean.
public String getType() { return type;}
public Boolean isPub() { return pub;}
Same as above. Boolean is an object reference type, which may end up
being null. Most of the time, you don't want a null for a boolean
value.
This is true of most of the primitive types.
Data classes frequently have the requirement to support
null for data not available or not applicable.
Which is why I used the phrase "Most of the time" as opposed to "All of
the time".
In my experience, it is more common for someone mistakenly choose a
wrapper than for someone meaningfully choose a wrapper. It is also less
common that someone mistakenly chooses a primitive over a wrapper.
Data classes and CRUD are a big part of IT.
And choosing a wrapper unnecessary have very small consequences
while mistakenly choosing a primitive is a real data integrity
problem.
I believe the opposite of your statement is true. Or at least some
compromise.
CRUD may be a big part of IT, but null values for every field are
required for well formed CRUD. Choosing a wrapper unnecessarily can lead
to NPE's or null-checks through-out code. Primitives guarantee non-null
values.
My point is to use a type which most closely matches your requirements.
If you really have a use-case where NULL is an acceptable and expected
value, then by all means use a wrapper. Otherwise you are asking for
trouble.
NULL/null is a very frequent valid value in real world data. Lack