Property type resolved from hidden superclass field instead of subclass field

[ilgrosso]

When upgrading our project based on spring-boot-data-neo4j from 4.0.6 to 4.0.7 (which brings spring-data-commons 4.0.5 -> 4.0.6 upgrade), we have noticed an error as described in this neo4j community post.

If we change our pom definition to keep spring-boot-data-neo4j:4.0.7 and spring-data-commons:4.0.5 all is working as expected.

I was trying to find anything relevant in the release changelog but could not get much out of it: maybe something related to type mapping caching?

[mp911de]

If you would like us to spend some time helping you to diagnose the problem, please spend some time describing it and, ideally, providing a minimal yet complete sample that reproduces the problem.
You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue.

[ilgrosso]

Description and reproducer added to spring-projects/spring-data-neo4j#3108

[mp911de]

This is indeed a regression introduced with 9ae4bf9. Many thanks to @meistermeier who helped us with tracing the problem.

When a subclass declares a field with the same name as a field in its superclass (but with a different type), TypeDiscoverer ends up resolving the property type from the superclass field rather than the subclass field that actually shadows it.

The reason is that ReflectionUtils.doWithFields visits fields from the leaf type upwards through its superclasses, and we added every visited field to the result map unconditionally. Since the superclass field gets visited last, it simply overwrote the entry that the subclass had already contributed, leaving us with the wrong property type for that name. Depending on the types involved, this can be merely surprising or actually incompatible.

We now keep the first field seen for a given name, so the shadowing subclass field wins as one would expect.