Nashorn: JavaScript made great in Java 8

JavaScript on the JVM is better and faster but not always friendlier with Nashorn, the rebuilt JavaScript interpreter

Page 2 of 4

Goals of Nashorn
Laskey described his goals for Nashorn as follows:

  • Nashorn will be based on the ECMAScript-262 Edition 5.1 language specification and must pass the ECMAScript-262 compliance tests.
  • Nashorn will support the javax.script (JSR 223) API.
  • Support will be provided for invoking Java code from JavaScript and for Java to invoke JavaScript code. This includes direct mapping to JavaBeans.
  • Nashorn will define a new command-line tool, jjs, for evaluating JavaScript code in "shebang" scripts, here documents, and edit strings.
  • Performance and memory usage of Nashorn applications should be significantly better than Rhino.
  • Nashorn will not expose any additional security risks.
  • Supplied libraries should function correctly under localization.
  • Error messages and documentation will be internationalized.

Laskey also explicitly limited the scope of the project with some "non-goals":

  • Nashorn will only support ECMAScript-262 Edition 5.1. It will not support any features of Edition 6 or any nonstandard features provided by other JavaScript implementations.
  • Nashorn will not include a browser plug-in API.
  • Nashorn will not include support for DOM/CSS or any related libraries (such as jQuery, Prototype, or Dojo).
  • Nashorn will not include direct debugging support.

So what does it mean to be based on ECMAScript-262 Edition 5.1? The differentiator here is that Rhino was based on the older, less capable Edition 3. The javax.script (JSR 223) API is for calling back into JavaScript from Java.

The lack of debugging support in Nashorn is a step backward from Rhino, which has its own JavaScript debugger. However, you'll find workarounds for this deliberate omission in at least two popular IDEs.

Nashorn command-line tools
After reading about jjs, I was eager to try out the shell on my iMac, but after installing Java 8 it wasn't available to the bash shell. It turns out the documentation and implementation weren't completely in sync.

I knew the installation had been successful:

>java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build 1.8.0-b132)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)

However, running jjs returned -bash: jjs: command not found. A little poking around brought me to the /usr/bin/ directory:

>which java

There I found something called jrunscript, which turned out to be a variant of jjs that runs an extra startup script. That should have satisfied me, but I was puzzled as to why the documented jjs tool wasn't installed in /usr/bin/ with the rest of the Java 8 runtime. A little research led me to look at the JavaVirtualMachines installation for Java 8. On a Mac, look for jjs in /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/ or /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/bin/.

You can define an alias for jjs in the latter directory and add it to your shell configuration if you need it for scripting on a Mac or Linux. On a PC, you can add the correct jre/bin/ directory to your PATH. In his video from the Java 8 launch, Jim Laskey suggests copying jjs to the /usr/bin/ directory, but when I did that I found that jjs couldn't find the jre properly at runtime.

| 1 2 3 4 Page 2