In Rhino imports for top-level java and javax packages were supported by simply declaring a variable with the fully qualified class name. This post highlights some of the differences between Rhino and Nashorn and demonstrates the recommended ways of importing classes and interacting with Java objects in Nashorn. While is is convenient, it is also unnecessary and incurs a performance impact. To ease the transition from Rhino to Nashorn a compatibility library was provided and could be utilized by including load("nashorn:mozilla_compat.js") at the beginning of a script. There were also differences in its interactions with native Java, in particular how Java classes are imported into a script. Starting with Maximo 7.6.0.6 (released in 2016), the Java 8 JDK became available and with it a new JavaScript engine from Oracle called Nashorn, which implemented JSR 292 and provided numerous performance and compliance enhancements. This post will describe the new Nashorn syntax for automation scripts.Īutomation scripts written in JavaScript prior to Maximo 7.6.0.6 used Java JDK 7, which included the Mozilla Rhino JavaScript engine. We saw earlier that the parametric equation of a line in terms of parameter t is defined as: x x + t a.
While it has been many years since the transition occurred, I still notice that even in modern implementations the old Rhino style is used with nashorn:mozilla_compat.js compatibility library unnecessarily loaded to support this legacy code. In general, we can describe the x, y, and z location of a parametric curve in terms of some parameter t as follows: x x ( t) y y ( t) z z ( t) Where: t is a range of real numbers. While writing some automation scripts for a recent project based on an older version of Maximo, I was reminded of the challenges of transitioning from the Java 7 to Java 8 JavaScript engines.
0 kommentar(er)
