JavaConfig bean resolution fails with generics + Kotlin declaration-site variance

[sdeleuze]

Declaration-site variance used in the very common kotlin.Pair class seems to impact bean resolution and currently prevents bean resolution to work as expected by the end user.

Based on an original report on Twitter, I have created a more focused repro project.

Following test works with class Tuple<A, B> but fails with class Tuple<out A, out B>, which is pretty hard to diagnose when the user is using kotlin.Pair which is provided in Kotlin standard library.

@RunWith(SpringRunner::class)
@ContextConfiguration(classes = [Config::class])
class TypeProjectionTest {

  @Inject
  private lateinit var ctx: Container<Tuple<String, String>>

  @Test
  fun testContext() {
  }

}

// Variant 1: works when not using declaration-site variance
//class Tuple<A, B>

// Variant 2: Fails with using declaration-site variance
class Tuple<out A, out B>

private interface Container<T>
private class ContainerTuple : Container<Tuple<String, String>>

@Configuration
private open class Config {

  @Bean
  open fun containerPair() : ContainerTuple {
    return ContainerTuple()
  }

}

@jhoeller Do you think there is something to refine in our bean resolution algorithm to support this kind of Kotlin declaration-site variance?

[encircled]

In the end in java code it is translated to Tuple<String, String> and Tuple<? extends String, ? extends String>, which is not allowed for injection (and should stay so I believe).

The only solution is to have kotlinized version of org.springframework.core.ResolvableType, where generic type variance would be available and can be considered when looking for the injection candidates.