jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <>
Subject Re: Nashorm Javascript engine
Date Mon, 14 Sep 2015 20:28:09 GMT
On Mon, Sep 14, 2015 at 4:51 PM, sebb <> wrote:

> On 14 September 2015 at 12:58, Vladimir Sitnikov
> <> wrote:
> >> Apart from compatibility issues [1]
> >
> > I do know there are compatibility issues, however is is rather smooth
> > if you are creating a new script.
> > I do know what "backward compatibility" is.
> It means that existing Javascript scripts will run without needing to
> be amended.

What is the probability to break a Javascript code in IF Controller ?
Complexity of such script would be very low.
I doubt  Rhino and Nashorn would differ in the way of interpreting those
Based on this:

Maybe the biggest risk is in replace, but I am not sure..

> >> I got the speed info from the diagram in the link from the Bugzilla:
> >>
> >
> > This benchmark makes very little sense. Proper benchmarking should
> > involve jmh [1]
> I quoted the URL because it was used in justifying Nashorn over Rhino.
> However the page clearly shows that Nashorn is not always faster.
> Given that
> - Nashorn is not always faster
Can you point to a particular case where it is not and that users would
meet in the JMeter scope ?

> - it may have compatibility issues
as long as we propose a way to select rhino and given that chances of
having regressions is very low, is it really a big risk.
In the benchmark I made using 2 IfControllers, there is a 50% increase in

it is clearly NOT OK to change JMeter without prior discussion of the
> issues.

I suppose we are discussing it here.

One side note.
Whenever a user migrates to Java8, the Javascript engine used by JSR223
Test Elements is switched without any other notice from RHINO to NASHORN.
In my opinion there are much bigger chances to break things  here as the
script has chances to be bigger.

> We may well decide that the advantages outweigh the disadvantages, but
> that discussion needs to occur and for agreement to be reached.
> >>Nashorn is NOT always faster than Rhino
> >
> > Well, what if it is faster in 99.9% cases?
> > I mean that we never find a library that will be always faster than
> > Rhino. There always be at lease a case or two where Rhino wins.
> > Does that mean we have to live with Rhino forever?
> No, but the decision needs to take these facts into consideration.
> > [1]
> >
> > Vladimir

Philippe Mouawad.

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