accessing java bean's property

[angelochen960]

Hi,

I have this bean:

public class Item {
private String type;
private Boolean pub;

public String getType() { return type;}

public Boolean isPub() { return pub;}
}


I can use item.getType() to get the type value, but I'm looking for a
generic way, say I have a string 'Type', then I'd like to get the
value of type of a certain object, any idea how to achieve this?
Thanks.

A.C.

 

[Daniel Pitts]

Hi,

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.

}


I can use item.getType() to get the type value, but I'm looking for a
generic way, say I have a string 'Type', then I'd like to get the
value of type of a certain object, any idea how to achieve this?
Thanks.

A.C.

Actually, it would be if you had the string "type", because that is the
name of the property. You can use introspection, or use a third-party
library (which uses reflection/introspection).

Spring has some good classes for this.

I often prefer OGNL for an embedded expression language.

So, the Big Question is, what are you *really* trying to do? If you
have to ask about reflection, then you are hopefully not working on a
production system. Reflection is useful for framework-type development,
but developing a useful and maintainable framework requires experience.
If you're playing around with reflection for fun and/or homework, then
have at it.

 

[Arne Vajhøj]

This should probably be a "boolean", not a Boolean.
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.

Arne

 

[Daniel Pitts]

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.

 

[SoftNum]

I hate to hijack this thread a bit, but I found it in my searching.

What I'm trying to do, which seems to fit into the usage model asked for by the first poster, is write a function to generate a generic Excel sheet based on a list of Java Beans and a list of properties, like a report. I'm using JPA, which is why these would be in Java Beans in the first place.

Instead of writing a special function for each table report they're going to want, I'd like to write one function, then just develop the list of properties as I need them.

Using the Sun Introspector class, this is what I've come up with for accessing a bean property by name.

(I know the class isn't very robust, and is probably error prone, but it's mostly just an example.)

	public Object getProprty(Object obj, String prop) throws 
		IntrospectionException, 
		IllegalArgumentException, 
		IllegalAccessException, 
		InvocationTargetException 								{
		
		BeanInfo bi = Introspector.getBeanInfo(obj.getClass());
		PropertyDescriptor pds[] = bi.getPropertyDescriptors();
		PropertyDescriptor theDescriptor = null;
		for(PropertyDescriptor pd : pds) {
			if(pd.getName().equals(prop))
				theDescriptor = pd;
		}
		
		return theDescriptor.getReadMethod().invoke(obj, (Object[])null);
		
	}

I just assume that something like this has been resolved before. The above code seems like it would be pretty slow. (My entity beans tend to have four dozen properties, and String compares aren't cheap.)

 

[Arne Vajhøj]

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.

Arne

 

[Daniel Pitts]

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.

 

[Arne Vajhøj]

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

 

[Daniel Pitts]

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.