Philippe>@All members, what do you think ? I guess this question is not only for committers, so don't hesitate to speak up.
Philippe>Maybe but in the current active members of the team how many are as good Philippe>in Kotlin as in Java ? Frankly speaking, I do not think that is the right question to ask. The adoption grows (e.g. see https://developers.googleblog.com/2021/11/announcing-kotlin-support-for-protocol.html ), and developers can get productive in 2 weeks. The language is statically typed, so there are no features that magically appear in the runtime. What you see is what gets executed. So I am sure, fixing a bug in Kotiln code is not dramatically different from fixing a bug in Java code. It might be even easier than fixing a bug in Groovy code since Groovy is dynamic. If fixing a bug or adding a feature requires creating new classes, you can still create Java classes. However, once you try Kotlin, you won't look back. Philippe>I am ok to use Kotlin when it brings missing features, but not when we can Philippe>use Java, in this particular case, I don't think those classes should be in Philippe>Kotlin in the PR: What do you think of scheduleParser.kt, scheduleTokenizer.kt, ThreadScheduleTest.kt? I think the files are more feature-dense than the files you listed, and if you are OK with reading scheduleParser.kt, scheduleTokenizer.kt, then PoissonRamp.kt, PreciseThreadGroup.kt, etc should not be a problem. Philippe>ok for DSL as I already wrote, benefit is clear I can easily imagine that making the existing classes dsl-friendly might require modifications. There might be dsl-only interfaces or classes. Do you mean we'll have to discuss the language for each and every class? Philippe>it's not used in the last PR right ? No, I do not use coroutines and jetpack compose for the new thread group. Philippe>Finalizing move to Java 11 without all the flags might be a first step. Philippe>What about compatibility of the libraries we use ? I think many are not Philippe>compatible. Frankly speaking, I've no idea, however, I assume we can use Java 17 without modules. In other words, we should be good provided the libraries do not use Unsafe and reflection against core Java classes. Our CI tests run with Java 14 now, and running with 17 should not be that different. Of course, migrating to Java modules would be a non-trivial task. However, I agree making all the clients use Java 17+ would be a non-trivial exercise for testing, documenting, etc. That means records, switch expressions, etc, are not really available for JMeter code, while Kotlin provides similar constructs right now. Vladimir
