Hi, I was a bit silent on the last discussion, so I try to combine my opinions on some of the points in this mail.
* Deprecating the "old" ThreadGroup. I think the old ThreadGroup has a nice and simple interface, that can be understood in a short time (my opinion :)). The new one should be as easy for easy use cases. Removing it would not be a good idea until the new one catches on (and even then might better be kept) * Semantic of the DSL That should probably be run on some users and hear their feedback. For me it was not clear, why "rate(0/min) even_arrivals(10m) rate(60/m)" would result in a continuous ramp up and not a sharp edged one. Maybe we could include the new Thread Group with a big *experimental* label for a while. * Including Kotlin and using it for further development I once tried Scala and liked it for my simple tests. I haven't really tried out Kotlin now, but I believe I could work with it. However I really like Eclipse as my IDE and don't know the state of usability it has reached regarding Kotlin. (I know, that I don't like working on the gradle files for exactly that reason). * Including lets-plot The examples on the github repo are looking really nice and a nice looking graphics is always a good way to attract more users. Therefore it would be cool to have it. But as Vladimir explained, it would add a lot of unwanted dependecies in the core. Could we work around this anyway? * Moving to a newer Java baseline That was a topic I wanted to ask for a long time. More and more libraries are 9+ or 11+ nowadays and we should follow up. I am uncertain, whether to jump to 17 or 11, but either way, I would really like to switch to something more modern. * Using the Java Module system I think it would be a lot of work to switch to the module system. We would have to clean up our jars to be exclusive owner of their packages, define the dependencies more explicit, look at our extensive usage of reflection, ... Is it possible to keep going on without the module system in newer Java versions? I have no idea. * New contributors falling out of the sky I would like to see that happen, but haven't observed it, yet :) Felix Am 05.11.21 um 22:35 schrieb Vladimir Sitnikov: >> I said that as scheduleParser.kt, scheduleTokenizer.kt are related to DSL, >> I am ok with them being in Kotlin. > Then it is a misunderstanding. > They implement a typical textbook regular-expression-based tokenizer and > parser. > > The files have nothing to do with Kotlin DSL for programmatic test plan > generation so far. > > Of course, DSL is a very broad term, however, the key aim of > scheduleParser.kt, scheduleTokenizer.kt > is to parse **string** with load profile configuration (e.g. "rate(5/sec) > random_arrivals(2 min) rate(10/sec)") > and convert it to Java objects or throw a parse error (e.g. in case a user > types an invalid time unit). > > That parsing logic can be implemented in Java, however, it would be > cumbersome taking into account Java 8. > >> Now if you don't work in Kotlin > My job is ~90% PL/SQL though. > >>> Philippe>Finalizing move to Java 11 without all the flags might be a > first >> step. > Philippe>What about this ? > > TL;DR: I would support that, however, I am not keen on spending my time on > doing the migration. > > Frankly speaking, I think Java 11 is out of date now, and, we, as an > application can move to Java 17 right away. > Here's Elasticsearch moving to Java 17: > https://twitter.com/xeraa/status/1455980076001071106 > Upgrading Java baseline is probably worth doing, however, it is not clear > what features does it bring. > > If we bump the baseline to Java 11 (or 17, does not really matter much), > then we probably can have access to a broader set of libraries. > For instance, https://github.com/kirill-grouchnikov/radiance is Java 9+. > > However, I am much more fascinated by creating the improved thread group, > creating Kotlin-based DSL for test plan generation, > creating in-core parallel controller, trying async clients (for HTTP/gRPC), > etc. > Java 11 does not seem to make those tasks significantly easier. > > Vladimir >
OpenPGP_signature
Description: OpenPGP digital signature
