Nashorn

Nashorn
Alan Wilson from Stilton, Peterborough, Cambs, UK · CC BY-SA 2.0 · source
Name	Nashorn
Developer	Oracle Corporation
Initial release	2011
Latest release	8u202
Programming language	Java (programming language)
Platform	Java Virtual Machine
License	GNU General Public License

Nashorn Nashorn is a JavaScript engine implemented for the Java Virtual Machine and distributed with OpenJDK and Oracle JDK. It was designed to provide a high-performance runtime for ECMAScript on the JVM while enabling interoperability with Java (programming language) libraries such as java.lang, java.util, and javax.script. Nashorn aimed to replace legacy engines in Oracle's Java stack and to serve developers building polyglot applications that combine Java EE components, Spring Framework modules, and Apache Tomcat deployments.

Overview

Nashorn implements the ECMAScript 5.1 specification and integrates with the JSR 223 ("Scripting for the Java Platform") API to allow scripting within JVM applications. It exposes javax.script.ScriptEngine semantics and supports calling into JavaFX UI code, integrating with Apache Maven build scripts, and embedding within Eclipse-based tooling. Nashorn targeted compatibility with mainstream JavaScript features used in environments such as Node.js and Mozilla Firefox, while emphasizing tight integration with Java SE classes like java.lang.String and java.util.concurrent.Future.

History and Development

The Nashorn project originated at Oracle Corporation as an effort to replace the older Rhino engine used in earlier Java SE distributions. Announced in 2011, Nashorn was developed by teams including contributors from Oracle Labs and aligned with initiatives such as Project Nashorn within the OpenJDK community. Early milestones included integration into JDK 8 and participation in the OpenJDK JSR review process for scripting. Nashorn's lifecycle intersected with broader Java Community Process discussions and coordination with projects like GraalVM that pursued alternative polyglot runtime strategies.

Architecture and Features

Nashorn compiles ECMAScript source to bytecode that runs on the JVM using facilities such as invokedynamic introduced in JDK 7. Its architecture leveraged the java.lang.invoke package and dynamic linking to optimize call sites for ECMAScript function calls and property access. Nashorn provided interoperability features that allowed scripts to instantiate java.util.ArrayList and call methods on java.lang.Object instances, perform reflection via java.lang.reflect.Method, and interop with javax.script.ScriptEngineManager. Security and sandboxing considerations were addressed through integration with Java Security Manager policies and ClassLoader boundaries. Nashorn also included debugging hooks compatible with JDB and could be invoked from build systems like Gradle and Ant.

Performance and Benchmarks

Nashorn emphasized performance improvements over Rhino by using just-in-time compilation patterns available on the JVM. Benchmarks conducted by community members compared Nashorn to engines such as V8 (JavaScript engine), SpiderMonkey, and Chakra (JavaScript engine), showing competitive performance for many scripting workloads while lagging on intensive numeric and DOM-oriented benchmarks representative of Google Chrome workloads. Performance tuning relied on HotSpot compiler heuristics, invokedynamic optimizations, and bytecode generation strategies compatible with Oracle JDK and OpenJDK HotSpot implementations. Enterprise benchmarking scenarios included embedding Nashorn in Apache Tomcat microservices and evaluating throughput with JMeter and latency with Gatling.

Integration and Usage

Developers used Nashorn to script Java SE applications, glue Spring Framework beans, prototype algorithms calling into Apache Commons libraries, and run server-side templates within Jetty or Tomcat containers. Tools and IDEs such as IntelliJ IDEA, NetBeans, and Eclipse provided varying degrees of support for editing and debugging Nashorn scripts. Nashorn could be invoked from the jjs command-line tool packaged with JDK 8 and integrated into continuous integration pipelines using Jenkins or TeamCity. Its interop model made it suitable for embedding third-party SDKs like AWS SDK for Java or Google Cloud Client Libraries into script-driven automation.

Deprecation and Removal from OpenJDK

As the Java Platform evolved, Nashorn was deprecated in JDK 11 and subsequently removed from later OpenJDK releases following proposals in the OpenJDK mailing lists and JEPs. The decision reflected strategic shifts toward projects like GraalVM and results of the Java Community Process that prioritized other approaches to polyglot runtimes. Deprecation discussions involved stakeholders from Oracle Corporation, Red Hat, and independent contributors, with transition guidance recommending migration to alternative engines or embedding solutions. Removal impacted distributions such as Oracle JDK builds and downstream projects relying on the jjs tool, prompting migration plans within organizations using Jenkins pipelines and Tomcat deployments.

Legacy and Alternatives

Nashorn's legacy persists in its influence on JVM polyglot strategies and the community knowledge captured in OpenJDK archives and GitHub mirrors. Alternatives that filled its role include GraalVM's JavaScript implementation, standalone engines like V8 (JavaScript engine), and integration approaches using Node.js via inter-process communication or adapters such as J2V8 and node-java. Projects such as Rhino remain options for specific compatibility needs, while enterprise tooling often recommends migrating to supported runtimes provided by vendors like Oracle Corporation or Red Hat that maintain long-term support. Nashorn contributed to discussions shaping modern polyglot platforms exemplified by GraalVM and influenced scripting integration patterns across Apache Tomcat, Spring Boot, and cloud-native environments like Kubernetes.

Category:Java platform