>There will be a meetup related to JMeter DSL tomorrow Here's the recording: https://youtu.be/FZOcmtp5sJY Thanks everybody for joining in less than 24h scheduling timeframe :)
It was nice to see you all, and it is great we have common issues, common ideas. Many thanks to Felix for emphasizing that participation in dev@jmeter discussions would make you closer to the core team, and it is important to hear opinions, ideas. I might be missing something, so please feel free to add/correct me. * I think nobody objected to programmatic DSL * There was an idea to activate GitHub Discussions for github.com/apache/jmeter project. I see it is possible by voting on a dev mailing list and then filing a ticket to INFRA (many ASF projects have already enabled Discussions) I'll start voting soon. * We diverted multiple times into "it would be great if TestElement API was refined" discussion, however, every time it ends up with "it is probably a lot of work". As I said earlier, I agree it would be great to refine TestElement API, however, I do not think that refinement is a pre-requisite for creating and delivering DSL. If there are ideas on that refinement, please feel free to start a discussion thread. * Someone mentioned certain TestElement features are in-UI only. For instance, sometimes "value validation" is implemented in GUI classes only, so all DSL implementations have to deal with it somehow. That is a nice finding, and I think we could make incremental improvements there. * There was a discussion regarding "incubating DSL in-JMeter" vs "incubating DSL out of JMeter and merging sometime later" I incline that we should incubate DSL in-JMeter for the following reasons: 1) Having something in-JMeter increases the visibility of the feature for the end-users 2) Having in-JMeter DSL allows immediate support DSLs for the newly added/modified in-JMeter components. We can't promote/reference third-party projects on the key JMeter pages due to ASF restrictions, so third-party projects need to do their own promotion. As for me, having something in-JMeter is really motivating. The alternative option is to "incubate out of JMeter, then weigh options, compare pros and cons", however, those activities do demotivate me. I could throw pros and cons, however, I would rather invest time on the feature itself rather than spend N months on pros and cons discussions :-/ By the way, recently Gatling team released what they call Java and Kotlin DSLs, so if we spend years on discussions, we would lag behind a lot. * We have discussed that Java, Kotlin, and Groovy might be viable languages for DSL, different people expressed their own opinions. I am not sure what is the summary though. First of all, I think Groovy is not that good fit for the JMeter DSL as * Groovy has a significant amount of magic (you don't see the errors in DSL immediately, and you basically need to execute it to find typos) * IDE support for Groovy is bad. I know there are gdsl files, however, overall IDE experience with Groovy is so-so, and writing gdsl files is a special skill * Groovy is a very rich language (especially when it comes to DSL), so automatic code formatting solutions are hard or they just do not exist * Groovy-Java integration is far from seamless * Groovy is rich, so refactoring is really hard: rename, "extract method", and other refactorings are hard or even impossible. For instance, once I tried to extract a helper method out of Jenkins Groovy DSL, and I had to add "resolveStrategy = Closure.OWNER_FIRST" to make it work. No way I could explain that to JMeter users. I am sure all the features of Java-based DSL can be easily implemented in Kotlin-based DSL. On the other hand, there are features that are trivial in Kotlin, yet they are hard or impossible in Java-based DSL. That is why I suggest we proceed with Kotlin-based DSL. Something that comes to my mind right away: * default values for parameters * named arguments * limited operator overloading. For instance, "5.seconds" or (a/b).roundToInt() are not possible in Java * DSL compatibility with the standard for/if constructs * simplified refactoring (e.g. select multiple lines of DSL and extract it into a method via default IDE features) * enhanced deprecation: warning, error, hidden, suggested replacements * multiline string literals (they exist in Java 15+, however, there are users who can't migrate to Java 15+ yet) * much stronger type inference. Kotlin is able to deduce types in many cases where Java stops. Java design focuses on "speed of compilation", so they have strict limits where inference stops and it requires user to specify the type. Kotlin focuses on pragmatic design, so it has much stronger type inference algorithms, so it is easier for developers to write code (e.g. less explicit types needed in generic-heavy code) Vladimir
