Great question! The key here is understanding how Spring Data leverages reflection and preserved generic type information (even with Java/Kotlin's type erasure) to avoid needing explicit Class<T> parameters like your mapV2 example. Let’s break this down step by step:

1. Spring Creates a Dynamic Proxy for Your Repository Interface #

When your Spring application starts up, it scans for all interfaces extending Spring Data repository types (like CrudRepository). For each interface, Spring generates a runtime proxy class (using JDK dynamic proxy or CGLIB) that implements your repository interface. This proxy handles all the heavy lifting of executing queries and mapping results.

2. Spring Resolves Generic Type Information from the Interface & Method #

Unlike your standalone mapV1 method (which loses generic type info at runtime due to erasure), Spring has access to the full static context of your repository interface and its methods:

Resolving Entity Type from the Repository Interface #

Your Repo interface extends CrudRepository<MyType, Long>. Spring uses reflection to parse the generic parameters of this parent interface:

• It calls Repo::class.java.getGenericInterfaces() to get the ParameterizedType representing CrudRepository<MyType, Long>.
• From this ParameterizedType, it extracts the first actual type argument (MyType) as a Class object.

Resolving Return Type Generics for Custom Methods #

For your custom abc(): List<MyType> method:

• Spring retrieves the method via reflection, then calls method.genericReturnType to get the generic return type (not just the raw List class).
• This return type is a ParameterizedType, so Spring can extract its actual type arguments (in this case, MyType).

Here’s a simplified Kotlin example of how this reflection works:

// Get the abc() method from the Repo interface
val abcMethod = Repo::class.java.getMethod("abc")
// Get the generic return type (List<MyType>)
val genericReturnType = abcMethod.genericReturnType
if (genericReturnType is ParameterizedType) {
    // Extract the element type of the List: MyType
    val entityType = genericReturnType.actualTypeArguments[0] as Class<MyType>
    println("Target entity type: ${entityType.name}") // Outputs MyType
}

3. Why Your Mapper.mapV1 Can’t Do This #

Your mapV1 method is a standalone generic method with no associated context. When you call mapV1<MyType>(source), the JVM erases the MyType parameter at runtime—there’s no way for the method to know what T is unless you pass it explicitly (like in mapV2).

Spring’s repository system doesn’t have this problem because it parses the static type information of your interface at application startup, before runtime erasure would obscure it. The interface’s structure (including generic parameters and method return types) is preserved in the class file, so reflection can access it.

4. Mapping Results to the Target Type #

Once Spring has the target entity type (MyType), it uses one of several mechanisms to instantiate and populate objects:

• For JDBC repositories, it might use Spring’s JdbcTemplate along with an auto-configured RowMapper that maps result set columns to MyType properties (using reflection to match column names to field names, or @Column annotations if present).
• It creates collection instances (like ArrayList for List<MyType>) and adds each mapped MyType instance to the collection.

Internal Spring Data Tools #

Spring Data uses a set of internal utilities to handle type resolution cleanly:

• The TypeInformation interface and its implementations (like ClassTypeInformation, ParameterizedTypeInformation) encapsulate generic type metadata, making it easy to traverse and extract type arguments from interfaces, methods, and fields.
• These utilities abstract away the complexity of reflection-based type parsing, so the repository proxy can focus on executing queries and mapping results.

内容的提问来源于stack exchange，提问作者Erik Madsen