Use the 4-argument `Property` constructor in SpEL's `ReflectivePropertyAccessor`

[sbrannen]

Overview

While reviewing #36911, I noticed that ReflectivePropertyAccessor currently invokes the 3-argument Property constructor which does not accept a predetermined property name and therefore ends up invoking org.springframework.core.convert.Property.resolveName().

However, the invocation of resolveName() seems unnecessary, since ReflectivePropertyAccessor already knows the name of the property.

Background

The 3-argument Property constructor has been in use since SpEL was introduced; whereas, the 4-argument Property constructor was added in 2012, in commit ca017a4 ("Introduce strategy for BeanInfo creation", SPR-9677) whose commit message states it was added specifically "allowing BeanWrapperImpl to specify the property name at construction time (as opposed to using Property#resolveName(), which supports the JavaBeans contract only)". So, it seems like it was simply an oversight not to migrate to the new Property constructor back then.

Related Issues

• Introduce strategy for BeanInfo creation [SPR-9677] #14311
• SpEL doesn't work nicely with records #26029
• Fix property name resolution for record accessors #36911

[lbkulinski]

@sbrannen I'm looking to contribute more to Spring and would like to take this issue on unless you were planning to

[sbrannen]

Hi @lbkulinski,

I'm looking to contribute more to Spring and would like to take this issue on unless you were planning to

Thanks for the offer! 👍

However, I created the issue and assigned it to myself. So, yes, that indicates that I will do it.

In fact, I completed the work two days ago: sbrannen@570250b

Regards,

Sam

[sbrannen]

After having written the corresponding tests, I determined that this is actually a "bug" rather than a mere "enhancement" due to the following:

• Record accessors whose component names embed or start with "get"/"is" (e.g., budget(), issue(), etc.) resolve to an incorrect and sometimes empty property name, causing Property#getField() to fail to locate the backing field — so its annotations are silently omitted from Property#getAnnotations().
• The same failure occurs for non-record "data classes" using the same bare-accessor convention (e.g., a hand-written island() accessor), causing Property#getField() to fail to locate the backing field — so its annotations are silently omitted from Property#getAnnotations().
• Acronym-style JavaBean properties (e.g., getURL()) resolve inconsistently (e.g., to "uRL" instead of "URL"), which can pick up annotations from an unrelated, similarly-named field instead of the correct one.

I am therefore labeling this as a "bug".