Hello, @Other team members, what's your opinion on this ? 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.
