Thanks Felix, Looks ok for me. What's your opinion on javascript function, should we follow the same strategy ?
Thanks On Wednesday, September 16, 2015, Felix Schumacher < [email protected]> wrote: > Am 15.09.2015 um 21:40 schrieb Philippe Mouawad: > >> Hello, >> @Other team members, what's your opinion on this ? >> > We shouldn't give up backward compatibility lightly. > > In case of the javascript interpreter, that comes with the jvm, I think it > is ok, to use the default interpreter of the jvm. The differences, that > were shown in the migration guide were not the ones, I would expect in > small scripts as they are probably found in the ifcontroller. > > But I would expect to have the same javascript environment in all places. > > Since the current stable version uses rhino, it could be a good strategy > to enable the use of nashorn, but leave rhino the default. Make a big note, > that we will switch to prefer nashorn in some near future, so that people > have a chance to test it and report problems. When no problems are > reported, we can switch to nashorn. > > Regards, > Felix > > >> Thanks >> Regards >> >> On Tue, Sep 15, 2015 at 7:38 AM, Philippe Mouawad < >> [email protected]> wrote: >> >> >>> 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. >>> >>> >>> >>> >>> >> > -- Cordialement. Philippe Mouawad.
