accessing java bean's property
in [Java Help]
|
Prev: Open popup from JSP - Servlet ??
Next: Date comparisons
From: Daniel Pitts on 17 Mar 2010 18:50 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(a)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. -- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Arne Vajhøj on 17 Mar 2010 20:49 On 17-03-2010 18:50, Daniel Pitts wrote: > 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(a)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 of information is common. Arne
From: Daniel Pitts on 18 Mar 2010 17:21
On 3/17/2010 5:49 PM, Arne Vajh�j wrote: > On 17-03-2010 18:50, Daniel Pitts wrote: >> 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(a)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 > of information is common. It may be common, but not universal. 1. Some data is required for a meaningful record. 2. Some data may be inferred from other data if not otherwise specified. 3. Some data may have a "sensible default". Those types of data should be non-nullable to ensure data consistency. -- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/> |