I do not think there are blockers, however: a) I use lets-plot for charting which is Kotlin library. I was not able to find a Java library (JFreeCharts license is not compatible with the ASF requirements) Frankly speaking, the chart was the last feature I added, and it was more of a coincidence. b) Kotlin covers null safety <-- in my opinion, this is huge c) There are cases for having Kotlin in project where Java solutions do not exist: DSL for programmatic testplan generation, coroutines (well, Loom + virtual threads might be just enough, however, the release date is moot), JetPack Compose might be a good fit for UI d) Kotlin is less verbose, and there are lots of convenience things like if-expressions, when-expressions, readonly lists and maps, and so on. e) Kotlin is easier to read: less verbosity yield better signal to noise ratio. Even though, IDEs can generate all the Java boilerplate code, and I do not type it, I still have to read it. f) The language interops with Java just fine, and it does not require data conversion.
I do not intend to rewrite the existing code in Kotlin in one day, however, I think it makes sense to write new code in Kotlin. By the way, it might be time to bump language version to Java 17 for JMeter code. Moving to 17 would ease some of the pain points (records, switch expressions), however, it does not resolve all of them. Vladimir
