Support Kotlin's function mangling

[d1snin]

From the Kotlin documentation:

To mitigate such issues, functions using inline classes are mangled by adding some stable hashcode to the function name. Therefore, fun compute(x: UInt) will be represented as public final void compute-(int x), which solves the clash problem.

Look at the following code:

@JvmInline
value class SomeEntityId(val value: String)

@Repository
interface SomeEntityRepository : JpaRepository<SomeEntity, SomeEntityId> {

    fun findSomeEntityById(id: SomeEntityId): Optional<SomeEntity>
}

Spring Data fails to parse findSomeEntityById function with the following error:

Failed to create query for method public abstract java.util.Optional dev.d1s.test.repository.SomeEntityRepository.findSomeEntityById-956swU4(java.lang.String)! Unable to locate Attribute  with the the given name [id-956swU4]

Currently, I can solve such a problem by adding the @JvmName annotation:

@Repository
interface SomeEntityRepository : JpaRepository<SomeEntity, SomeEntityId> {

    @JvmName("findSomeEntityById")
    @Suppress("INAPPLICABLE_JVM_NAME")
    fun findSomeEntityById(id: SomeEntityId): Optional<SomeEntity>
}

But I find this quite problematic to include these two annotations every single time on every single repository method consuming Kotlin's inline class.

IMO, there is a way to tolerate function mangling. You can simply detect it and cut off the hashcode part from the method name.

[mp911de]

Kotlin's inline-class mechanism randomizes any method names that touch the surface of inline classes. We have the ticket #1947 to address inline classes support so closing this one as duplicate. We also see that Kotlin's approach is less than ideal as it invalidates all assumptions made by frameworks that rely on property names and property paths.

[d1snin]

Ok, TY! I'll track the progress on the issue you linked.