>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
