Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Nashorn Voted In as a Successor to Rhino in the OpenJDK Project

Nashorn Voted In as a Successor to Rhino in the OpenJDK Project

This item in japanese

The current OpenJDK members have voted Oracle's Project Nashorn, a new JVM-based JavaScript implementation, as a successor to Rhino which is the current JVM JavaScript implementation. Nashorn is due for release with Java 8 in late 2013. It allows JavaScript to be embedded in Java applications and to develop standalone JavaScript applications.

In November 2012, InfoQ covered John Coomes’ (OpenJDK HotSpot Group Lead) proposal to replace Rhino with Nashorn. Later in December last year, according to the official Nashorn blog, the project team led by Jim Laskey has got the project into OpenJDK. According to the latest entry on its official blog, Nashorn is available to developers who can browse the source, build and play with the project’s code-base. The project team behind Nashorn aims to put in larger integration work.

Oracle announced Nashorn at the JVM Language Summit in summer 2011 with a goal to promote the JVM relevance as a multi language platform. JSR-292, an inclusion in Java 7 in 2011, primarily focuses on the needs of dynamic languages. Covered comprehensively in InfoQ back in early 2010, JSR-292 adds invokedynamic instruction so that the Java bytecode can call methods which have linkage and dispatch semantics defined by non-Java languages. Many of the existing dynamic languages on the JVM are upgrading their implementations to use invokedynamic. Jim Laskey covers very well the relationship of Nashorn with JSR-292 through his video titled "Adventures in JSR-292 or How To Be a Duck Without Really Trying".

The main advantage of having JavaScript running on the JVM is that it gives access to the vast array of pre-written Java libraries. On the Nashorn blog, Jim has covered an example which shows Nashorn’s seamless workings with the Java libraries Twitter4J and JavaFX. The interop is handled via the Dynalink library which provides a set of agreed conventions for specifying higher level operations on objects in a program execution environment, and ships with a linker for plain Java objects.

Through the Twitter4J and JavaFX example, Jim Laskey mentions:

Also note, that Nashorn is magically handling the generic class FXCollections. Finally, with the call to observableArrayList(dates), Nashorn is automatically converting the JavaScript array dates to a Java collection. It really is hard to identify which objects are JavaScript and which are Java.

The Nashorn project team during JavaOne 2012 experienced a lot of questions centered on Nashorn and Node.jar. Node.jar is a server-side JavaScript framework – a blend of evented model, APIs of Node.js, features of Nashorn, Grizzly from GlassFish for async network I/O with a support for developers for running Node applications with Java SE and Java EE. Seeing the response they received at JavaOne, the Nashorn team Jim Laskey et al. believes that the Nashorn + Node.jar combination currently generates a lot of interest in the developer community.

It is possible to virtually meet the Oracle Nashorn JavaScript team through the Birds-of-a-Feather BOF media presentation hosted through the JavaOne 2012 site.

Rate this Article