On Fri, 2005-06-17 at 15:36 -0700, Will Pugh wrote: > I sent off a mail to the CGLib alias to see if there is any workaround. > > I am still a bit perplexed about the differences between > BeanUtilBean.copyProperties and PropertyUtilBean.copyProperties, why are > they different? Why are there two? I noticed that the copyProperties > in BeanUtilBean is more complicated (in that it can deal with > expressions) but copyProperties will never actually send it expressions > any more complicated than property name. The only other difference I > see is that BeanUtilBean.copyProperty will try to convert a property in > the case you have same name different types rather then just exploding. > Is there a reason PropertyUtilBean.copyProperties does not want to convert?
>From the javadocs for BeanUtilBean.copyProperties: * <p>If you know that no type conversions are required, the * <code>copyProperties()</code> method in [EMAIL PROTECTED] PropertyUtils} will * execute faster than this method.</p> Sometimes you don't want type conversion to occur; you know there is no need for it so there's no point in calling a method that might try to do type conversion. Nothing in the entire PropertyUtilBean class uses ConvertUtils. And when cloning a bean you obviously don't need typeconversion; by definition the target properties for the copy have the same types as the source properties. So BeanUtilsBean.clone calls the faster and simpler method. I agree with Wendy about CGLib method naming being in violation of the javabeans standard. You can probably work around this for the meantime by defining a BeanInfo class for the problem class, but pushing CGLib to fix their class is a good idea. As for why BeanUtilsBean.copyProperties catches exceptions from getSimpleProperty while PropertyUtilsBean.copyProperties does not - well, yes they should probably have been consistent. No doubt they were written months apart, possibly by different people, and just weren't done quite the same. However fixing this isn't likely now as changing either behaviour would probably fall into the category of non-backwards-compatible-change. And anyway the problem will only be caused by non-javabeans-compliant input classes, so the real fix is fixing the bean you're trying to copy. Note that BeanUtils isn't the best designed of libraries; it really needs a rewrite. However there's an extremely low probability of that happening. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
