My main concern with using something like this in a business is whether it will still be maintained a decade or two from now. Kotlin has the support of several major players in the Java ecosystem and is virtually guaranteed to stick around. If JADEx is abandoned, it becomes an additional maintenance burden on the team.

(Though point in your favor, they can maintain it since it’s open-source. Greybeards have nightmares about updating critical projects reliant on old, long-abandoned abandoned C/C++ dependencies.)

Unlike a Kotlin migration, there’s no new language for the whole team to learn, no need to flip the entire codebase at once.

Kotlin is designed for trivial bidirectional Java interop. Mixed-language projects are explicitly supported as a basic feature, so you don’t have to convert the entire codebase at once. You can go through file-by-file, rewriting a single class in Kotlin at a time, same as in JADEx.

I’ll admit null safety in a mixed codebase can be a pain* - though I’m guessing JADEx doesn’t escape that pain point either. Edit: the same issues Kotlin has are mentioned in the article, though both languages provide tools to find and fix them.

* Also needing to spam @JvmName and @JvmStatic everywhere to make everything compile into the proper Java equivalent. Moving statics to an auto-generated ClassNameKt.class by default and the whole companion object model are the two things I hate most about Kotlin.