jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <>
Subject Re: About including Groovy
Date Wed, 02 Mar 2016 22:06:07 GMT
For information , we had a vote on our twitter account:

Results are the following:
Participation : 100 Votes
- 9% NO
- 91% YES

This has no particular value except to give a kind of feeling about it.

>From this discussion it appears we have a move towards including it.

Unless there is a NOGO I will start bundling 2.4.6 groovy-all in jmeter
tomorrow evening.


On Thu, Feb 25, 2016 at 3:53 AM, Vladimir Sitnikov <> wrote:

> TL;DR:  +1 for bundling proper groovy.jar with JMeter.
> Alternative approach would be some kind of "online store to download
> JMeter plugins". I am not sure if that can be done in a reasonable
> time frame though.
> In my opinion, there are number of advantages for bundling Groovy:
> 1) I can easily get a "online groovy console", so I can easily check
> if -3.abs() returns 3 or -3. That is exactly JMeter users have to do.
> JMeter (as IDE) does not provide ability to execute small parts of
> code, thus users have to use their minds (or Google or whatever) to
> craft code that works. I claim using Groovy online console helps a
> lot. With BeanShell you never know if your code will work until you
> run it.
> just blows BeanShell out of the water.
> 2) "Groovy is in active development, thus everybody would have to
> constantly update groovy.jar anyway" is not justified.
> Even though there will be new groovy.jar releases, it is unlikely
> users will use cutting-edge features of Groovy language in JMeter
> scenarios.
> I think the main usage would be just regular boilerplate code, so
> non-experts would never be able to write Groovy code that requires the
> latest groovy.jar to execute.
> 3) Even though I prefer not to use Groovy, I see no better replacement
> for glue code in JMeter's samplers. In fact, it could even make sense
> to add a menu entry like "create groovy samlper". That way users could
> access it without secret knowledge of what JSR223 means.
> 4) Groovy's Java interop is much better designed from language point
> of view than the one of JavaScript. I mean it is just much easier to
> call java libraries since that was considered by Groovy language
> designers. This somewhat rules out JavaScript. BeanShell is too
> verbose and it does not seem to be the right tool as a glue language.
> As a Java programmer, I'm much more fluent in "Groovy+groovyconsole"
> than in "BeanShell+no_way_to_validate_snippet".
> I'm fluent in JavaScript, yet it does not help me to answer "how to
> read/write a file". Rhino/Nashorn have java interop, yet it is not in
> my active vocabulary, thus I would prefer groovy.
> 5) It is a bit hard to pick the proper groovy jar.
> 6) At the end of the day, "valid java code is valid Groovy code"
> 7) Having Groovy in JMeter would add nice "backward compatibility"
> feature. Suppose JMeter 3.0 includes Groovy. Then load scripts would
> work in exactly the same way for all the users of JMeter 3.0. If
> everybody downloads his/her own version of Groovy, that would easily
> result in "JMeter script broken for unknown reason" or even "wrong
> results due to newer/incompatible groovy.jar version".
> sebb> The only advantage I can see is that JMeter users don't have to
> sebb> download Groovy in order to use it.
> That is huge advantage.
> Current is not designed for
> downloading a single jar file.
> "" is 35MiB zip file with lots of jars
> inside. Technically speaking, 52 of them start with "groovy-"
> I do not want to learn/read which groovy jar I need. I just want to
> make JMeter work.
> Milamber>2/ Why Beanshell is including in JMeter and not Groovy?
> I think it might be a good time to deprecate BeanShell. Not in a sense
> "remove it in the subsequent release", but in order to clean up menus,
> etc, etc. One never has excessive screen space, so removing BeanShell
> menus seems wise from my point of view.
> sebb> This adds aboiut 5% to the total jar size.
> That is OK from my point of view.
> Current includes:
> 1) Lots of javadocs (docs/api). 46MiB when unzipped. That is more than
> 50% of the JMeter (82MiB is the net volume of unzipped JMeter 2.13).
> If removing docs/api, the zip file takes 5MiB less. I'm not sure
> javadocs need be the part of regular JMeter binary zip.
> 2) Current docs/images/screenshots takes 12MiB. It can likely be fit
> under 5MiB (~save 10MiB) if crunched through a png optimizer.
> Vladimir

Philippe Mouawad.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message