On Tuesday, September 15, 2015, sebb <[email protected]> wrote:
On 14 September 2015 at 21:28, Philippe Mouawad
<[email protected]> wrote:
On Mon, Sep 14, 2015 at 4:51 PM, sebb <[email protected]> wrote:
On 14 September 2015 at 12:58, Vladimir Sitnikov
<[email protected]> 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 ?
Depends on what the incompatible changes are.
so what do you propose ?
Complexity of such script would be very low.
Probably, but that does not mean the script cannot break.
so you want the statu quo ?
I doubt Rhino and Nashorn would differ in the way of interpreting those
scripts.
That may be true but is just guesswork without more evidence.
I don't know what to say. I tend to think we have very low risk to have
issues here, we mention the incompatible change so user check their script
once they upgrade.
And if any regression they have the option to debug or revert to old
behaviour.
Backward compatibility is rather well managed here. It should not be a
stopper for any change in JMeter.
New scripts are built on nashorn and that 's it.
You think something else, why would I have to prove that it will not break
, and not you prove that it will?
In my opinion unless you have a big explicit case where it breaks I see no
reason not to move forward.
Based on this:
https://wiki.openjdk.java.net/display/Nashorn/Rhino+Migration+Guide
Maybe the biggest risk is in replace, but I am not sure..
This needs to be established.
what do you propose ?
I got the speed info from the diagram in the link from the Bugzilla:
http://ariya.ofilabs.com/2014/03/nashorn-the-new-rhino-on-the-block.html
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.
We don't yet what the chance of regressions is.
the migration guide does not show big regression risks.
In the benchmark I made using 2 IfControllers, there is a 50% increase
in
throughput.
it is clearly NOT OK to change JMeter without prior discussion of the
issues.
I suppose we are discussing it here.
Yes, we are now.
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.
That's not quite true.
If the user originally selected "rhino" then the test plan will fail
because "rhino" has been dropped as a valid engine.
As a standard user, would you choose javascript (very well known) or
rhino(more specialized ) ?
I think most users choose javascript.
Seeing lot of questions on JMeter at stackoverflow , they frequently
mention js or javascript.
However if they selected "javascript" or "js" then they will get the
default JS engine.
And in this case there are chances to break.
In my opinion there are much bigger chances to break things here as the
script has chances to be bigger.
It is likely that such scripts will be bigger, however the user will
get a clear warning if they selected Rhino specifically.
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] http://openjdk.java.net/projects/code-tools/jmh/
Vladimir
--
Cordialement.
Philippe Mouawad.
--
Cordialement.
Philippe Mouawad.
