jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: About including Groovy
Date Wed, 02 Mar 2016 23:12:31 GMT
On 2 March 2016 at 22:06, Philippe Mouawad <> wrote:
> Hello,
> For information , we had a vote on our twitter account:
> -
> Results are the following:
> Participation : 100 Votes
> - 9% NO

What reasons were given for saying 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.
> Regards
> Philippe
> 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
> --
> Cordialement.
> Philippe Mouawad.

View raw message