BeanUtils.copyProperties() to not set collection fields of wrong generic type [SPR-15689]

[spring-projects-issues]

Elad Tabak opened SPR-15689 and commented

org.springframework.beans.BeanUtils.copyProperties() copy fields of generic collections even if the generic types do not match.
This result in a strange behavior when a bean that have a collection of <A> will get values of <B>.
See example class:
There are two bean classes - X and Y. Both have a field "list" of different types - X have a list of <A> and Y have a list of <B>.
The result after a BeanUtils.copyProperties(x,y) is that y have a list of <A> even though it's a type mismatch.

Generic data is problematic to establish in case the collection is empty, but if it's not, it's possible to not set the field. Of course this is a best-effort for a specific use case of 2 beans of different types.

---

Affects: 4.3.9

Attachments:

• TestBeanUtils.java (1.10 kB)

[snicoll]

Sorry this got overlooked. With a supported Spring Framework version, that sample produces the same output as commons-beanutils. Pease note that BeanUtils, as stated in the javadoc, is mainly for internal use within the framework. If it doesn't suite your use cases, then using commons-beanutils is what you should be doing.

[tzvatot]

While I understand the lack of interest to fix internal function, it still does not make sense for this behavior to remain in the code. At some point, it will be misused internally as well and will break. But I guess that will be the incentive to fix it then.

[snicoll]

As I've said, both commons-beanutils and our BeanUtils behave the same way with a supported version of the framework. I did stop at that as I thought the sample was using commons-beanutils as an argument it doesn't have that problem.