How about using Kotlin as a primary DSL?

rabelenda commented 3 years ago

Hello,

Thank you very much to bring this topic into discussion. Is a really interesting topic to talk and think about.

We implemented the DSL in java since Java is more established, more popular (easier to get contributions), is easily used in most of other JVM languages (kotlin, groovy, scala, etc), is the language JMeter is built in into, doesn't require any additional dependencies/libraries, and is the language we have more experience with.

We have in the backlog to provide examples in other popular JVM languages (like kotling, groovy, etc) on how the API could be used with them, and get a glimpse on how they look like. And when we do, we might identify some modifications or additions that may simplify the API usage with such languages and following their conventions (that might not necessarily be the same as java) and styling.

What is the main focus of your question? are you asking about improving the experience for Kotlin users? are you more interested on implementing the DSL itself in Kotlin to attract Kotlin eager devs to contribute? What particular pros and cons you see with Kotlin vs Java?

I like very much Kotlin syntax and some of it's features, but there are other points to take into consideration. Would really like to have an example and to ease as much as possible usage from Kotlin.

I open up the discussion for anyone that wants to contribute points to this discussion, and provide alternatives and thoughts.

Thank you again to bringing this to attention and taking time to review the DSL and create this issue.

Regards

vlsi commented 3 years ago

Kotlin provides better DSL, and it enables extensible DSLs . For instance, if something is missing, then it can be added via extension fun. That is not possible with Java DSL.

I am inclined that it might be worth having in-core kotlin-based dsl

vlsi commented 3 years ago

What is the main focus of your question?

Sorry for disturbing the flow, however, I was just not sure how to approach it.

I've recently bumped the "JMeter DSL" thread on the dev list: https://lists.apache.org/thread/52o722d7npsjj99m4k2zdz44mstl02lg, and adding DSL to JMeter core might be not that far away.

I see you did a lot of things (the documentation looks AWESOME by the way), so I asked your opinion.

is the language JMeter is built in into, doesn't require any additional dependencies/libraries

Well, I think Kotlin will be in the core dependencies quite soon (see https://github.com/apache/jmeter/pull/674 )

rabelenda commented 3 years ago

Hello,

What about building on top of the java DSL a kotlin DSL that provides better features for kotlin users? You can use the kotlin extension/DSL if you want the additional requirements of kotlin libs and language knowledge?

About adding a DSL to the core JMeter, we initially thought about the option of directly contributing to JMeter, and is not something we discard for the future to contribute this project to JMeter project. But we thought it required first to be proved and tested by the community to validate if the idea is useful for the community and gets some tracking, and after the idea being proven and the community shows interest, then maybe propose integrating it with core JMeter.

At current status I think we still need more traction/popularity, and complete a little more the spectrum of JMeter core features to consider it mature enough to contribute it to JMeter core.

We are always open to ideas and comments to improve the DSL, so discussing about such matter could be a topic for another issue in the repo, and we can talk further if makes sense to contribute the project to JMeter core, and how to do that in a sane/smooth way. I currently see that there is value in merging into JMeter core, but there is also value for both following separate paths, focusing in separate audiences and prioritization while both benefiting from each other.

It would be awesome to add something in JMeter doc or communications channels referring to the DSL so as to validate how much people that goes to JMeter page/docs, are actually more interested in using it from a DSL than using the GUI. I see it also as an option to avoid users not using JMeter, and going for other options, due to preferring a more programmatic way of defining and running test plans.

Thank you again for all the info, the proposal and taking time to discuss about it.

vlsi commented 3 years ago

But we thought it required first to be proved and tested by the community to validate if the idea

Ah, same here. However, now I am inclined that it is worth shipping something and mark it as @Incubating so there's no fear of "breaking things"

What about building on top of the java DSL a kotlin DSL that provides better features for kotlin users?

That would be more work (maintaining both Java and Kotlin DSLs usable), and Java limits what could be done in DSL.

For instance, how do you add httpSampler in a loop? How do you add httpSampler in a conditional manner? With Java you are stuck with varargs (I guess it is what you use in jmeter-java-dsl) or builders (https://github.com/anasoid/jmeter-as-code). varargs provide no way to add if/for, and builders are too verbose :'(

It would be awesome to add something in JMeter doc or communications channels referring to the DSL

The ASF policy regarding third-party code is moot for me when it comes to "promotion of third-party software". For instance, once there was a discussion to integrate JMeter plugin manager (a third-party tool) since it is used by virtually all the users. However, the conclusion was it would violate the ASF rules :-/

rabelenda commented 3 years ago

Hello,

That would be more work (maintaining both Java and Kotlin DSLs usable), and Java limits what could be done in DSL.

In some sense, yes, but I think it should be not much effort, since core should not change much, and the kotlin extension could be automatically generated (and manually tuned when needed) from the java DSL. We could start that way and see how much effort it is, and doing so we avoid any of the potential drawbacks of following an all-in approach with kotlin (first try an extension, as an incremental approach, and then see if makes sense to keep it that way or go with another approach, like all-in).

About adding samplers in a loop or conditionally: can you provide examples when that could be needed and how that would look like with a potential kotlin DSL? Currently with the DSL you could build the list of children of an element using standard programatic constructs (if, fors, etc) and then pass that as parameter of the thread group (or whatever test element you want as parent). I don't know is a valid alternative to what to intend, but in particular I am interested in the particular use case you envision when you would require that (build a test plan dynamically, if I understood correctly your idea/needs).

Regarding the ASF policy, I think in general if you get the approval and proper mention/attribution from/to the authors, everything should be good. I don't follow you though on how that actually relates to adding a reference to another third party tool as part of the community of JMeter or the tool itself. I have seen such mentions and references to third party tools that enrich the tool environment across several open source initiatives, and I think is an awesome way to collaborate in mutual promotion and benefit, collaborating and trying to increase the community, support, usability, etc.

I am really interested on the plugin manager discussion, can you provide some link about it? It sounds really interesting.

Thank you again to invest time and providing additional insights, info and ideas.

Regards

vlsi commented 3 years ago

I don't follow you though on how that actually relates to adding a reference to another third party tool

See https://lists.apache.org/thread/sfszw52d1to98vgpkkh0xh4dlylzbf7b and https://www.apache.org/foundation/marks/linking#productsupport

About adding samplers in a loop or conditionally: can you provide examples when that could be needed and how that would look like with a potential kotlin DSL?

For instance, debugging samplers could be added like if (debug) { debugSampler(...); log.info("...") } for and if could be useful when building a load schedule as well :)

loadProfile {
    for (i in 1..10) {
        rate(i*10 / second)
        randomArrivals(5.minutes)
        rate(i*10 / second)
    }
}

vlsi commented 3 years ago

I don't follow you though on how that actually relates to adding a reference to another third party tool as part of the community of JMeter or the tool itself.

Here's one more instance: https://lists.apache.org/thread/21hw6n9zkt7qqslmnzc0q70mzgm4rzgf

It looks like there's no problem if the third-party plugins are mentioned on JMeter wiki. I've no idea how popular the wiki is, however, I think I never used it, so I never discover JMeter plugins via JMeter wiki :-/

rabelenda commented 3 years ago

Thank you very much for those links!

The discussion is very interesting, and in particular the part about avoiding favoritism. I think that in general if there is an easy way for anyone to publish to the list, it should be "fair enough" and avoid favoritism. That would avoid asking people to google by themselves and have to take aside the noise by themselves. The main solution I usually use to discover tools around one project is searching in github, or some twitter accounts, but would be really nice to have something near the tools (which I have seen pretty common referenced in OSS projects, it seems Apache projects are more conservative in that regard. For instance I think this is a great resource: https://github.com/aliesbelik/awesome-jmeter

About the wiki, yes, I know about it (due to my experience developing plugins for jmeter), but I think most users don't. Maybe JMeter should make it a lot more visible and important. Maybe using it as main documentation site and avoiding having a separate site for it. Having two sources of documentation may cause confusion, and issues for finding the actual/relevant/up to date info.

Now, going back to the kotlin DSL, we are now evaluating alternatives, and balancing pros and cons, as soon I have news I will let you know.

Regarding the particular use case you provided, as I mentioned, you could do similar stuff with the DSL, maybe not as direct as with kotlin, but for example the if example you provided could be done with a ternary operator in the list, ignoring null elements in the list (in the DSL), and the for case, I am still not sure of it's value. For the for you could use forLoopController, or create a builder method with the for returning the list of elements. It seems pretty corner case and easily and cleanly solvable by other means (even though in kotlin might be simpler). Aside from these points, as I previously mentioned we are investing time on evaluating a kotlin DSL extension, and potentially implement de core with kotlin (I don't think we will end in this, but we still need to review this option in more detail).

Regards, and thank you very much for all the info, and all the ideas for thought that you have brought.

vlsi commented 3 years ago

Now, going back to the kotlin DSL, we are now evaluating alternatives, and balancing pros and cons, as soon I have news I will let you know.

Great

Regarding the particular use case you provided, as I mentioned, you could do similar stuff with the DSL, maybe not as direct as with kotlin, but for example the if example you provided could be done with a ternary operator in the list, ignoring null elements in the list (in the DSL), and the for case

That's the difference: with Kotlin one can use regular language features to "extract method with repetitive elements", "add if, for here and there". It just works, and you don't need to think about how to squeeze what you want through the limits of Java :)

vlsi commented 3 years ago

I think that in general if there is an easy way for anyone to publish to the list, it should be "fair enough" and avoid favoritism

Those are my thoughts as well. However, I'm not that long with the ASF, so I do not know what is the spirit behind the rule of "third party mentions are not allowed in project webpages".

It might be that @sebbASF could clarify.

For instance, if we consider "JMeter wiki" and "component reference" at https://jmeter.apache.org/, then the pages do not look significantly different. So if there's an option to reference third-party plugins at wiki, then it should not be that different from having exactly the same kind of mention at the component reference page.

However, I have not explored that.

kirillyu commented 3 years ago

Sounds epic cool.

kirillyu commented 3 years ago

There are also a number of advantages in favor of Kotlin for me:

the code size there is 30-40% less,
there is an extend function - it can add any method to any class from anywhere, which is useful in using the ready-made jmeter engine for DSL, so it will be convenient to expand without changing source code and without complex override constructions,
exception handler is really more friendly,
finally it has full compatibility with java classes, moreover, there is a quite not bad converter.

kirillyu commented 2 years ago

Seems like we can close it now. Yes?

rabelenda commented 2 years ago

Is something we want to invest, we haven't had time yet to fully dedicate to it, but hope to have some news, maybe for may/june.

We have kept it open so people are aware that is an open request. But maybe, to avoid having issues dangling we can close it, and if someone has interest, they can comment and we can reopen.

abstracta / jmeter-java-dsl

How about using Kotlin as a primary DSL? #30