Is BeanShell Dead?
Last year, with the release of Apache JMeter™ 3.1, the Apache team made Groovy the default scripting language for the JSR223 Sampler. This change was not accidental. With the growth of Groovy’s popularity across the developers’ community, it became obvious that Groovy language provides many more benefits as a JMeter sampler than any other scripting language.
Before the transition to Groovy, the king of scripting languages for JMeter performance scripts was BeanShell. With the change being over six months old, I thought it would be interesting to see if the transition to Groovy left its marks on the JMeter community, and why.
Groovy vs. BeanShell on StackOverflow
First of all, I thought about the best way to compare the popularity of BeanShell and Groovy usage across the JMeter community. If we think about the best place to find trends in the IT community, the answer is obviously StackOverflow.
If we search for “BeanShell and JMeter” on Stack Overflow, we can see there are almost 850 search results*:
But when searching for “Groovy and JMeter”, there are only around 260 results*:
*the two searches were conducted on July the 2nd, 2017
At first glance, based on the number of related topics in StackOverflow, we can see there is a huge BeanShell advantage. But let’s be wise and make a detailed comparison of the last two years. To do that we need to check how many BeanShell and Groovy topics were created for each month during the past two years.
The numbers look interesting:
I created a distribution graph for better visualization:
The trend is that there are less topics created about “BeanShell and JMeter” during 2017, in comparison to 2016. At the same time, we can see the growth of Groovy popularity, and the trends looks optimistic in 2017.
The most interesting fact that we can see is a the starting point when Groovy started its growth in 2016. This point correlates with release of JMeter 3.1 version, which happened on November 2017. This research confirms that the Apache JMeter team achieved the goal of popularizing Groovy as the script language for the JSR223 Sampler.
But is this growing popularity related only to that trivial change of the default option for the JSR223 Sampler scripting language? Or is this trend is based on Groovy advantages over BeanShell? Let’s dive deeper into this question.
Along with substitution of the default scripting language for the JSR223 Sampler, there was one more major change. Since JMeter 3.1, Groovy dependency became an official and default part of the out-of-the-box bundle. This is a big change that has the power to change the whole picture!
As a result, the usage of Groovy with JMeter became much straightforward, since you do not need to spend time on additional configuration and integration of Groovy jar with JMeter itself. Most developers prefer to use out of the box functionality, if it enables reaching established goals.
But there are more reasons for preferring Groovy. Developers often debate fiercely about which tool is better and which language should be the only one used. But this doesn’t occur over Groovy and BeanShell in integration with JMeter. In fact, most developers who tried both languages in JMeter, usually choose Groovy. Why?
First of all, based on its performance. There are many examples of developers who faced an issue where their scripts became unstable with BeanShell and a huge number of load threads. Most of these cases were managed by transition from BeanShell to Groovy.
This is thanks to Groovy’s compilation capabilities, which enable Groovy to compile the code to bytecode. The bytecode can then be handled more efficiently by the Java Virtual Machine.
Compilation provides benefits when testing heavy loads, since the same code is compiled only once at the beginning of test. This is very important since the performance of internal JMeter elements is extremely important for performance scripts overall.
Moreover, many developers are very happy about Groovy providing syntax sugar, like this article. ‘Syntax sugar’ means language constructions that allow writing code in a more clean and simple way, which makes it easy to read and maintain.
In the long-term perspective, it is important to use tools that have ongoing development support and imply some sort of an evolution. When you stand between two choices of tools/languages/frameworks, it is always better to check how the development is advancing for both of them.
As BeanShell and Groovy are both open-source languages, it is very easy to check their development history on public repositories.
You can see that Groovy is still in extensive development. This means better support and more syntax options for the future.
If you want to check additional advantages of Groovy over BeanShell in integration with JMeter you can read the blog post “Apache Groovy - Why and How You Should Use It”, which describes many of those.
Should you take all your existing scripts which contain BeanShell code and make a transition to Groovy tomorrow? I don’t think so. If BeanShell works for you and if you didn’t have issues before, then your needs are fulfilled and the transition will probably be a waste of time.
Should you try to use Groovy for the next test if you have used only BeanShell until now? Yes, it is definitely worth it!
Want to learn more? You might be interested in viewing the webinar, Advanced JMeter Scripting - Writing Assertions in Groovy.
To learn more about JMeter, check out our free JMeter academy.
To start testing with BlazeMeter, which enhances JMeter abilities, just put your URL or JMX file in the box below, and your test will start in minutes.