Java Magazine, July/August 2017

ORACLE COM JAVAMAGAZINE JULY AUGUST 2017 34 java 9 Nashorn the JDKs built in JavaScript engine has undergone a variety of improvements in this new release Before diving into those enhancements let me briefly set the context for these changes so that their addition makes the most sense Background When I started the development of Nashorn in late 2010 I was just looking for a way to experiment with the newly minted invokedynamic JSR 292 byte code instruction The JVM team later adopted Nashorn as a test bed for invokedynamic and the Nashorn Project drove much of the performance improvements made to the invokedynamic implementation While this was going on the Java group was discussing how JavaScript would likely grow to dominate client side development and that integrating JavaScript with Java would be a critical element of the client server equation Rhino an open source implementation of JavaScript from the Mozilla Foundation that was then the JDK ofering for JavaScript was getting long in the tooth and further development was winding down In November 2012 JDK Enhancement Proposal JEP 174 Nashorn JavaScript Engine was approved which enabled work to begin in earnest to provide a fresh robust secure full featured implementation of ECMAScript 262 Edition 51 ES5 to run on the Java platform Initially Nashorn found a home in a wide variety of applications such as app servers JavaFX applications utilities shell scripts embedded systems and so on Nashorn continues to have broad usage but its use appears to have settled into three main areas The development of JavaScript applications that can be run on both the client and the server In the JavaScript world this is known as isomorphic development The advantages are huge for smaller shops that want to build front ends for both desktop and mobile services a single programming language with a common codebase and rapid delivery Isomorphic development also scales well for larger systems Runtime adaptive or dynamic coding The term I like to use is soft coding where portions of an application can be modified after the application server is deployed This capability is used for everything from stored procedures in databases to application configuration management Shell scripting This consists of using JavaScript in areas where bash or Python would traditionally be used There is often a lot of debate about Nashorns performance on the JVM compared to native JavaScript performance on platforms such as Googles V8 Nashorn starts out slower because it translates the JavaScript to bytecode After that Nashorn is at the mercy of HotSpot to deliver native code This approach works well for long running server applications but not as well for small and run once scripts The main reason we developed Nashorn in the first place was to run JavaScript and Java together seamlessly Most Nashorn applications do a great job of orchestrating JavaScript and Java something that V8 was not designed to do JIM LASKEY Nashorn JavaScript Engine in JDK 9 Handy additions and support for ES6 make Nashorn even more useful