Well, it quickly turned out this was not a good idea. My initial idea was to keep the existing (java) integration test code as it is, and add the new kotlin sub-project (as I'm converting them).

The gradle project architecture was pretty old-school with a number of sub-projects (not a big fan of that). So, why not to use it for integration testing sand bring the whole code to a single stack? Starting point There is Gradle plugin support as well (the we use as well for building). Highly interoperable, and as other currently known scripting languages, pushing the development towards functional programming, writing immutable code. Moreover, the big heads are working to bring it to embedded systems and iOS too. Therefore, it works easily with any Java written web, client, server application and Android (Google officially supports it). Kotlin is a programming language developed by JetBrains and works everywhere Java Virtual Machine (JVM) works. (No one likes to spit himself to the face :)) Kotlin behind the scenes having different test stack from the product in one repository is a no-go for me. The only excuse I had, we forked down our code from an existing product but yeah.nah. The reason was very simple: a couple of weeks ago a reviewer on our team's PR pointed out that the integration tests were written in Java while our API's code was 90% Kotlin (10% mixed with Java).

Kotlin serializable data class