On Fri, Nov 5, 2021 at 9:18 PM Vladimir Sitnikov < [email protected]> wrote:
> Philippe>@All members, what do you think ? > > I guess this question is not only for committers, so don't hesitate to > speak up. > For me, contributors opinion has the biggest weight . But I am ok to see what all say. > > 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. > I think it is :-) > 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. > Maybe if you use Kotlin every day within your work (because you have to otherwise you can leave) then maybe you'll be able to move forward , but I don't believe that in 2 weeks you'll be the equivalent of what you are in Java. Now if you don't work in Kotlin, and have to learn it on your little remaining time (not speaking about personal , family time) , then for sure in 2 weeks I won't be. > 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. > I said that as scheduleParser.kt, scheduleTokenizer.kt are related to DSL, I am ok with them being in Kotlin. I didn't say they were easy to read. > 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. > What about this ? > 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. > I agree > That means records, switch expressions, etc, are not really available for > JMeter code, while Kotlin provides similar constructs right now. > > Vladimir > -- Cordialement. Philippe Mouawad.
