On Fri, Nov 5, 2021 at 7:58 AM Vladimir Sitnikov < [email protected]> wrote:
> 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. > no problem for this one, I agree it's very hard to find a good OS friendly API for charting in Java. b) Kotlin covers null safety <-- in my opinion, this is huge > this is not significant enough for me c) There are cases for having Kotlin in project where Java solutions do not > exist: DSL for programmatic testplan generation, ok for DSL as I already wrote, benefit is clear > coroutines (well, Loom + > virtual threads might be just enough, however, the release date is > moot), it's not used in the last PR right ? 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. > Maybe but in the current active members of the team how many are as good in Kotlin as in Java ? Although it's great you're contributing actively these last weeks, what will happen when you'll be less active ? I must say I consider myself a very junior in Kotlin, while I hope I am a bit better in Java. And regarding verbosity, sometimes it gives more readable/immediately understandable code IMO. 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. > It's an opinion. I don't have the same. As of me, I don't find it easier to read at all. f) The language interops with Java just fine, and it does not require data > conversion. > Agreed. > 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. > I think that would require a discussion before going further. I am ok to use Kotlin when it brings missing features, but not when we can use Java, in this particular case, I don't think those classes should be in Kotlin in the PR: - src/core/src/main/kotlin/org/apache/jmeter/threads/precise/PoissonRamp.kt - src/core/src/main/kotlin/org/apache/jmeter/threads/precise/PreciseThreadGroup.kt - src/core/src/main/kotlin/org/apache/jmeter/threads/precise/PreciseThreadGroupController.kt - src/core/src/main/kotlin/org/apache/jmeter/threads/precise/ThreadScheduleProcessGenerator.kt - src/core/src/main/kotlin/org/apache/jmeter/threads/precise/gui/PreciseThreadGroupGui.kt Those are critical classes if the element is used and we will have to dig into edgy cases , as of me, I don't feel confident enough maintaining current PR code @All members, what do you think ? > 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. > Finalizing move to Java 11 without all the flags might be a first step. What about compatibility of the libraries we use ? I think many are not compatible. > Vladimir > -- Regards Philippe M. Ubik-Ingenierie
