Fix property name resolution for record-style accessors

[junhyeong9812]

Overview

org.springframework.core.convert.Property#resolveName() derives a property
name from a read Method. It located the get/is accessor prefix with
String#indexOf, which matches the prefix anywhere in the method name.

Problem

For record-style plain accessors (supported since gh-26029) whose property name
contains such a token, the wrong portion is stripped. Because is is a very
common bigram, this is not limited to contrived names — many ordinary component
names are affected:

accessor	current result	expected
budget() / widget() / gadget()	"" (empty)	budget / widget / gadget
issue() / island()	sue / land	issue / island
history() / distance()	tory / tance	history / distance
decision() / visible()	ion / ible	decision / visible

An empty/incorrect name then makes Property#getField() fail to locate the
backing field, so annotations declared on that field are silently dropped.

This affects not only Java records but any "data class" with record-style
accessors, such as Kotlin data classes and hand-written Java data classes.

Fix

Match the get/is prefix only at the start of the method name via
startsWith, and do not strip it when the method is a plain accessor for a
data class — that is, a non-static no-arg method referring to an instance
field of the same name (mirroring the core signal of
CachedIntrospectionResults#isPlainAccessor). This supports Java records,
Kotlin data classes, and custom Java data classes alike, without relying on
java.lang.Record or RecordComponent.

Regular JavaBeans accessors without a backing field of the same name are
unaffected.

Note on impact

A getter that is backed by an instance field of the exact same name — for
example private boolean isUrgent; with public boolean isUrgent(), the shape
Kotlin produces for val isUrgent and that a record component named
isUrgent produces — now resolves to the field name (isUrgent) rather than
the stripped form (urgent). This keeps the resolved name aligned with the
backing field (and the record component name), at the cost of diverging from
java.beans.Introspector for that specific shape; the two cases are
structurally identical, so they cannot be distinguished reflectively. This is
pinned by resolveNameForBooleanGetterBackedByFieldOfSameName and called out
here for explicit review.

Tests

PropertyTests covers standard getters, boolean getters and setters; a getter
embedding get mid-name (isTarget(), the original defect shape); record
accessors that embed (budget) or start with (issue) a prefix; plain record
accessors; a JavaBeans getter declared on a record; record components literally
named get, is, and getWidget; the same scenarios on a hand-written
non-record data class; a field-backed isUrgent() getter; and static
method/field edge cases.

[junhyeong9812]

One note in case it helps: this PR bundles two independent changes, and only the first is needed for the defect.

1. Record component accessors resolve to a wrong or empty property name (budget() -> "", issue() -> sue), so Property#getField() misses the backing component field and annotations declared on that component are dropped.
2. The setter branch switches from indexOf("set") to startsWith("set"). That one is a behavior change - write methods that are not setters were accepted before and now throw IllegalArgumentException.

The two are separate blocks in resolveName(), so dropping (2) leaves the record fix intact. If (2) is the part that makes this worth deliberating, I can push a version that touches only the record path and leaves the setter branch as it is.

[sbrannen]

Good catch, and thanks for the PR! 👍

I've requested changes to support "data classes" in general, not just Java records.

Also, please note that I raised #37123 to address issues within SpEL's ReflectivePropertyAccessor, which I've already implemented in sbrannen@d8df4bb.

So, thanks for bringing this issue to my attention.

Cheers,

Sam

[sbrannen]

Spring's "record-style accessor" support was never scoped to java.lang.Record. Rather, we support Java records, Kotlin data classes, and custom Java "data classes" (whose accessors look like those of a Java record).

Thus, isRecordAccessor() should be renamed to something like isPlainAccessor(), and it needs to be revised to support those additional "data class" use cases without the use of isRecord() or RecordComponent – for example, mirroring the logic in ReflectivePropertyAccessor.findGetterForProperty(...) or
CachedIntrospectionResults.isPlainAccessor().

In addition, please introduce tests which cover those scenarios – or rather at least the Java "data class" use case, since that should cover the Kotlin data class use case as well. For inspiration, see sbrannen@d8df4bb.

[sbrannen]

The two are separate blocks in resolveName(), so dropping (2) leaves the record fix intact. If (2) is the part that makes this worth deliberating, I can push a version that touches only the record path and leaves the setter branch as it is.

Actually, yes, please do extract the setter changes into a separate, dedicated PR with an appropriate title.

[junhyeong9812]

Thanks for the review! I have updated the PR as requested:

• isRecordAccessor() is now isPlainAccessor() and no longer relies on isRecord()/RecordComponent. It treats a non-static no-arg method that refers to an instance field of the same name as a plain accessor, mirroring the core signal of CachedIntrospectionResults#isPlainAccessor, so custom Java "data classes" and Kotlin data classes are covered as well.
• Added tests for a hand-written non-record data class (embedded prefix, leading prefix, plain, and a conventional getter without a backing field), plus static-member edge cases.
• The setter changes have been reverted from this PR and extracted into Reject write methods not starting with "set" in Property #37139 as suggested.
• One behavioral note flagged explicitly in the updated description ("Note on impact"): a getter backed by a field of the exact same name (for example isUrgent() with a boolean isUrgent field — the shape produced by a record component or Kotlin property named isUrgent) now resolves to isUrgent rather than urgent.
• The branch has been rebased onto the latest main and squashed into a single commit.