Since the release of Helsinki, the Service Now Documentation contains this text:
(Screenshot of the Madrid Documentation)
This sounds as if Rhino 1.7R5 was something fancy and new. In fact, Rhino 1.7R5 was released in January 2015. At the time of this writing, this was exactly four years and three months ago. This is not exactly what I would run under the label "Javascript Engine Update".
Especially if you consider that Rhino is the very interface you are programming against in your daily life as a Service Now programmer. Of course, you can also add Java Code, but this is rather rare. Also the statement "You can use modern library code.." is cool - because you will not be able to leverage any post 2016 Javascript features. This starts with very basic things like the missing let keyword, but also means that there are no promises and other advanced features available.
Also from a security point of view I think it's not justifiable to use such an old library.
Before you ask: Yes, I talked about this with Service Now (in a HI Incident, when I noticed that the call stack in case of an exception behaved like in an old Rhino version). I was told the newer versions of Rhino did not add anything worthwile. I cannot quite follow this argumentation. More likely is that it takes a long time to re-write all the legacy code in modern Javascript.
I had a recent problem with Rhino (but I am not sure if a newer version would have helped). I wrote a simple function to perform search and replace using a regular expression, however, it was not executed correctly. As it it often the case, Stackoverflow was my rescue. Rhino did not treat my string as a Javascript sting, but as a java.lang.String (you can find out about this by using JSUtil.logObject). This class does not implement the .replace() method.
The only way out is to cast the java.lang.String to a Javascript string by using
var strClean = new String(strInput);
Funny enough, the Service Now editor then remarks "Do not use String as a constructor", which is very helpful indeed.
Bottom line: I really hoped the library would be newer in Madrid, but as you see above, this is not the case.
(Screenshot of the Madrid Documentation)Especially if you consider that Rhino is the very interface you are programming against in your daily life as a Service Now programmer. Of course, you can also add Java Code, but this is rather rare. Also the statement "You can use modern library code.." is cool - because you will not be able to leverage any post 2016 Javascript features. This starts with very basic things like the missing let keyword, but also means that there are no promises and other advanced features available.
Also from a security point of view I think it's not justifiable to use such an old library.
Before you ask: Yes, I talked about this with Service Now (in a HI Incident, when I noticed that the call stack in case of an exception behaved like in an old Rhino version). I was told the newer versions of Rhino did not add anything worthwile. I cannot quite follow this argumentation. More likely is that it takes a long time to re-write all the legacy code in modern Javascript.
I had a recent problem with Rhino (but I am not sure if a newer version would have helped). I wrote a simple function to perform search and replace using a regular expression, however, it was not executed correctly. As it it often the case, Stackoverflow was my rescue. Rhino did not treat my string as a Javascript sting, but as a java.lang.String (you can find out about this by using JSUtil.logObject). This class does not implement the .replace() method.
The only way out is to cast the java.lang.String to a Javascript string by using
var strClean = new String(strInput);
Funny enough, the Service Now editor then remarks "Do not use String as a constructor", which is very helpful indeed.
Bottom line: I really hoped the library would be newer in Madrid, but as you see above, this is not the case.
Comments
Post a Comment