I first learned Java in 1997 and have been using it professionally since 2005. If your Kotlin code is pretty indistinguishable from your Java code, you aren't using Kotlin properly. Here is what I wrote on this topic in 2022:
Here are some of my favorite Kotlin improvements over Java that I leverage all the time:
* Much improved type system (nullable types, function types, declaration site variance, type aliases, contracts, better type inference, reified function type arguments)
* Local variables are final by default ("val")
* Type-level distinction between read-only and mutable collections (but compiled to Java collections under the hood, so no conversion required when interacting with Java)
* Much improved collection API
* Much improved lambdas (e.g., no pain points w/ mutating variables and checked exceptions)
* Extension functions (incredibly useful in practice)
* Much better DSL capabilities (great for UIs, generating HTML, etc.)
Many of Kotlin's profound improvements will never find their way into Java because it's 25 years too late to do so. Java improves where it still can, which is the right thing to do. Sometimes Java even manages to improve on Kotlin because now it can learn from Kotlin and other languages. Nevertheless, it's impossible for Java to catch up to Kotlin, which was designed 15 years later with the explicit goal of fixing as many of Java's design mistakes as feasible for a JVM language.
If you think Kotlin is marginally better than Java, you probably have a superficial understanding of Kotlin. Kotlin is vastly better than Java, which isn't surprising because Kotlin was designed 15 years later with the explicit goal of being a better Java and fixing as many of Java's design mistakes as possible. For example, the designers of Kotlin went through the book "Effective Java" and tried to avoid the listed pitfalls by design.
Java will never get close to Kotlin because even though Java can, and thankfully does, still improve, it's too late to revise many of it design decisions, and large language features often need to be considered in a language's design from the start.
On Android, Kotlin is an even bigger win because Android uses an old Java version and has become Kotlin-first.
In my opinion, Java will remain the best choice for libraries that target multiple JVM languages. For everything else, I use Kotlin without thinking twice. Kotlin 2.0 laid the groundwork for toolchain improvements, which have indeed been a long-standing pain point.
I'm afraid that no current config language is an obvious fit for Mill. That's because Mill is fully reactive and doesn't distinguish between build configuration and execution by design.
I gave Mill a try earlier this year. My hope was to escape the nightmare that is Gradle, which I've been using for many years. Mill sounds great in theory (except for the Scala DSL). Unfortunately, I couldn't get a basic Java build to work in half a day, even though I have (admittedly rusty) working knowledge of Scala. It was one obscure error after another. My conclusion was that Java support isn't ready. There was also very little documentation on how to build Java.
In my opinion, using a GPL as the build language of a polyglot build tool is a dead end, both for technical/usability reasons and because the ensuing language wars can't be won. I'm looking forward to the day when a build tool embraces a modern config language such as CUE or Pkl.
Refactorings are one example where LSP can’t match IntelliJ. A language server also takes far more skill and effort to implement than the equivalent IntelliJ plugin, where much of the heavy lifting is done by the IntelliJ framework. And you still need at least a lightweight plugin for each supported editor. That’s why a language server isn’t necessarily the best place to start but hard to avoid in the long run.
Java doesn’t have a universal practical solution for this. Principled solutions based on custom class loaders (such as OSGi) added tremendous complexity and created more problems than they solved. Other solutions such as shading (renaming classes and their usages to prevent name conflicts between different versions) work in some cases but have their own limitations and drawbacks.