Jdbi: Erreur de méthodes ambiguës (méthode du pont manquant) pour la surcharge covariante Kotlin

Salut Tor,
Nous avons testé qu'une construction très similaire fonctionne en Java vanille : https://github.com/jdbi/jdbi/blob/master/sqlobject/src/test/java/org/jdbi/v3/sqlobject/TestSqlObject.java#L293 - L307
Peut-être avons-nous raté une affaire pour Kotlin. Nous devrions ajouter ici un test correspondant à votre utilisation et corriger tout bogue découvert.

Ah, en y regardant de plus près : notez que les types de retour sont différents, Object vs UUID . Je suppose que cela signifie que le compilateur Kotlin émet une méthode de pont synthétique que nous ne gérons alors pas correctement.

Pour les personnes qui recherchent Google, ce bogue génère un message d'erreur différent lorsque l'interface parent n'est pas annotée (il m'a fallu un certain temps pour le trouver !)

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 , c'est un problème légèrement différent. J'ai amélioré le message d'erreur pour ne pas être trompeur sur la classe à laquelle il manque l'annotation : https://github.com/jdbi/jdbi/pull/1590/files#diff -75b1c04d402bd8924262c7fececfcdb1L166

@TorRanfelt , j'ai creusé un peu plus là-dedans et il n'est pas évident de savoir quoi faire pour y remédier. Il semble que le compilateur Kotlin n'émet pas de méthode de pont pour la spécialisation de méthode covariante. J'ai déposé un problème sur le bug tracker de Kotlin : https://youtrack.jetbrains.com/issue/KT-33634

Comme solution de contournement, Jdbi pourrait émuler la méthode de pont nécessaire. Le code nécessaire finit probablement par être petit mais très difficile à écrire. J'espère que Kotlin évaluera au moins le problème bientôt.

@stevenschlansker Merci pour votre recherche.
Kotlin a dû avoir ce pont avant parce que je l'ai vu fonctionner. - Cela explique pourquoi je n'ai pas pu le faire fonctionner à nouveau en revenant aux anciennes versions de JDBI.

Il semble que ce soit un compromis pour maintenir la compatibilité Java 6 : 6 ne supportait pas les méthodes de pont dans les interfaces, donc Kotlin ne les émet pas. Cela semble idiot de nos jours, mais cela avait probablement du sens il y a 10 ans ;) Espérons qu'ils abandonneront bientôt le support 6, ou au moins activeront conditionnellement la compatibilité avec le monde post-6.