Jdbi: Error de métodos ambiguos (método de puente faltante) para la sobrecarga covariante de Kotlin

Hola Tor,
Probamos que una construcción muy similar funciona en Java vainilla: https://github.com/jdbi/jdbi/blob/master/sqlobject/src/test/java/org/jdbi/v3/sqlobject/TestSqlObject.java#L293 - L307
Quizás perdimos un caso para Kotlin. Deberíamos agregar una prueba correspondiente a su uso aquí y corregir cualquier error que se descubra.

Ah, mirando más de cerca: tenga en cuenta que los tipos de devolución son diferentes, Object vs UUID . Supongo que esto significa que el compilador de Kotlin está emitiendo un método de puente sintético que luego no estamos manejando correctamente.

Para las personas que buscan en Google, este error produce un mensaje de error diferente cuando la interfaz principal no está anotada (¡me tomó un tiempo encontrar esto!)

Exception in thread "main" java.lang.IllegalStateException: Method StringRepo.get must be default or be annotated with a SQL method annotation.
    at org.jdbi.v3.sqlobject.SqlObjectFactory.lambda$buildMethodHandler$15(SqlObjectFactory.java:148)
...

interface Repo<T> {
    fun get(): T
}
interface StringRepo : Repo<String> {
    @SqlQuery("SELECT 'Hello world!'")
    override fun get(): String
}
//...snip
jdbi.onDemand(StringRepo::class.java).get()

@LittleMikeDev , ese es un problema ligeramente diferente. He mejorado los mensajes de error para que no sean engañosos sobre la clase a la que le falta la anotación: https://github.com/jdbi/jdbi/pull/1590/files#diff -75b1c04d402bd8924262c7fececfcdb1L166

@TorRanfelt , https://youtrack.jetbrains.com/issue/KT-33634

Como solución alternativa, Jdbi podría emular el método puente necesario. El código necesario probablemente termine siendo pequeño pero muy complicado de escribir. Espero que Kotlin al menos evalúe el problema pronto.

@stevenschlansker Gracias por investigarlo.
Kotlin debe haber tenido este puente antes porque lo he visto funcionar. - Esto explica por qué no pude volver a hacerlo funcionar volviendo a versiones anteriores de JDBI.

Parece que esto fue un compromiso para mantener la compatibilidad con Java 6: 6 no admitía métodos de puente en las interfaces, por lo que Kotlin no los emite. Eso suena muy tonto hoy en día, pero probablemente tenía sentido hace 10 años;) Con suerte, dejarán de admitir 6 pronto, o al menos permitirán la compatibilidad condicionalmente con el mundo post-6.