On Thu, 19 Apr 2001 [EMAIL PROTECTED] wrote:
> I'm quite new with the bean reflection. So, sorry if it is a stupid question.
>
> How can I have extra info on the bean properties. Specially is it an
> transient property or not ? The only way is via the Modifier class or
> are there other techniques ?
>
Beanutils itself cares only about JavaBeans properties -- things that are
accessible through getter and setter methods that follow the right naming
conventions. Note that there need not be an actual variable that
corresponds to the property value; it might be calculated in the getter.
The "transient" modifier applies specifically to an instance variable (and
not to the property access methods). There is nothing that ties the name
of a particular instance variable (even if it exists) to a particular
property, so there is no way to introspect any sort of relationship like
this -- you have to know the underlying code.
> My real problem is :
>
> Some time, I want to store a bean into a persitence store. BeanUtil is
> a good candidate for doing that. Some attributes are just using for
> computing or performance reason => transient. So, there is no reason
> to update them. My idea is get all "non-transient" properties (from
> the ancestor top => the bean) and used them to update my legacy
> persistent store. How I can doing that based on the BeanUtil
> components ?
>
Doesn't standard Java serialization do exactly what you want?
> Second question, what about the perfomances. Is it true that
> reflection in java are not good for the performances ?
>
There are two performance "hits" to be aware of:
* The first time a bean is accessed, the properties of that bean
must be introspected. Beanutils caches the results of this by
saving the set of PropertyDescriptors that are returned (and you
can ask for them via PropertyUtils.getPropertyDescriptors()).
* For each call to a getter or setter, there are a few extra
operations to look up the appropriate property (HashMap lookup),
set up the calling arguments, and so on. The actual method call
is fairly close to the same sort of thing that the compiler generates
when it creates bytecodes for a standard method call, although it
is still a little bit generalized.
The tradeoff, of course, is that introspection lets you decide at runtime
which method to call -- otherwise you have to decide at compile time.
> Many thanks,
> Christophe
Craig McClanahan
