Problems with TestContainers and Kotlin

[iirekm]

TestContainers depends on construction of raw types and pattern like class C<SELF extends C<SELF>>. Unfortunately Kotlin, and probably other JVM languages don't like it - see https://youtrack.jetbrains.com/issue/KT-17186

Adding static factory methods could solve those problems.

[martin-g]

My workaround is:

class KGenericContainer(imageName: String) : GenericContainer<KGenericContainer>(imageName)

And use it everywhere I'd need otherwise to use GenericContainer.
Charming, isn't it ? :-)

[rnorth]

Yeah, I'd not appreciated this would be a problem with Kotlin but it's unfortunate :(
@bsideup, something to consider for the next version...

[asafm]

Just reading this generic expression gives you a headache :)

…

On Sat, 1 Apr 2017 at 20:09 Richard North ***@***.***> wrote: Yeah, I'd not appreciated this would be a problem with Kotlin but it's unfortunate :( @bsideup <https://github.com/bsideup>, something to consider for the next version... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#318 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA8Y8Rglpfbh-GydCPzdE7d_W1nkn8FMks5rroTOgaJpZM4Mvb7T> .

[mpecan]

This is related directly to #238 and can be resolved in the way that was suggested by @bsideup (#238 (comment)).

[mkobit]

Another ugly way to handle this as described in the YouTrack issue:

val container: GenericContainer<*> = GenericContainer<Nothing>()

[helmbold]

@mkobit Method chaining as shown in the docs is not possible with your approach ( GenericContainer<Nothing>()).

I suggest to use the workaround from @martin-g instead.

[kiview]

First time I tried to use Testcontainers with Kotlin and ran into exactly this problem, so great it found the workarounds here 😅

[alex0ptr]

@helmbold Chaining is easily possible with Kotlin native scoping functions, example:

val container: GenericContainer<*> = GenericContainer<Nothing>()
                                        .apply{ withExposedPorts(6379) }

I'll make a merge request to propose this in the Kotlin Examples.

[xyzwps]

I created a sub class of MySQLContainer:

internal class SpecifiedMySQLContainer(val image: String) : MySQLContainer<SpecifiedMySQLContainer>(image)

val mysqlContainer = SpecifiedMySQLContainer(image = "mysql:5.7.28").withDatabaseName("dbname")

[thaibt]

Another ugly way to handle this as described in the YouTrack issue:

val container: GenericContainer<*> = GenericContainer<Nothing>()

This saved my life... Was to frustrated and I did not find this thread.

[schnapster]

Looks like Kotlin 1.5.30 ships with a preview for 1.6 that fixes this: https://kotlinlang.org/docs/whatsnew1530.html#improvements-to-type-inference-for-recursive-generic-types

[sdeleuze]

Please close this issue as Kotlin 1.6 which fixes it has been released.

[bsideup]

@sdeleuze good point!
It is great to see Kotlin supporting more and more "in the wild" cases 🎉
IIRC some Spring's builders also benefited from it? Double win!

[sdeleuze]

Yep indeed that fixed a few Spring builder APIs as well. I am glad the Kotlin team has listened feedback from the community to fix this really annoying issue.