|Component||core-libs / jdk.nashorn|
|Discussion||nashorn dash dev at openjdk dot java dot net|
|Reviewed by||Sundararajan Athijegannathan|
|Endorsed by||Brian Goetz|
Design and implement a new lightweight, high-performance implementation
made available to Java applications via the existing
and also more generally via a new command-line tool.
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.
Nashorn will define a new command-line tool,
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.
Nashorn will not include a browser plugin API.
Nashorn will not include support for DOM/CSS or any related libraries (e.g., jQuery, Prototype, or Dojo).
Nashorn will not include direct debugging support.
It is also in the interest of the Java community to promote the JVM as a viable platform for languages other than Java. This advances the technology and attracts new developers.
The lexer takes an array of Unicode characters (source) and translates it into a stream of lexical units or tokens; e.g., numbers, strings, identifiers, or special characters.
Code generation is done in two steps. The first step lowers the AST/IR to something closer to the JVM instruction set. This conversion includes transforming controls, reducing expressions to primitive operations, and simplifying call expressions. This step is also responsible for defining symbols used to manage data usage, space, and types.
Step two translates the AST/IR into byte code via the ASM library. ASM emits the actual byte codes to form a script class. This class is cached in memory for later use by the script loader.
Once the script class has been generated, it needs to be installed into the JVM. This is done using defineClass via a secure custom class loader. This loader is also used to synthesize special Nashorn object classes when encountered in generated code. Once the script class is loaded, its runMethod is invoked.
Several libraries are needed to support the executing code.
The main runtime library includes methods that directly support executing
code, e.g., type-conversion routines needed for
toNumber, and allocation routines like
The linker library includes methods to assist the binding of
invokedynamic calls using the
java.lang.invoke API (JSR 292). The
binding process is quite complex, searching for the correct method,
defining guards to ensure that call sites continues to be the correct,
and relinking if something changes to require a different correct
method. The linker also manages a history of calls, so that lookup is
faster on successive relinks.
RegExp, and so forth. It also includes functions for
string manipulation, complex math, applying functions, et cetera.
invokedynamic to implement all of its invocations. If an
invocation has a Java object receiver, Nashorn attempts to bind the call
has full discretion about how it resolves methods. As an example, if it
can't find a field in the receiver, it looks for an equivalent Java Bean
Java developers can use the
javax.script (JSR 223) API to evaluate and
Rhino has a long history, and source code to match. Most of the Rhino code supports an interpreted execution model. To gain significant performance, the execution model needs to take advantage of the Hotspot interpreter/compiler.
Existing javax.script JCK test should be sufficient. Nashorn is just
another scripting engine accessible via the
javax.script API. Nashorn
itself does not expose its own new Java standard API, so no additional
JCK tests are needed.
Existing tests include:
These cover most of the functional areas, but these tests have to be adapted into Nashorn's TestNG-based test suite. Not all of these tests may be applicable since Nashorn is ECMAScript-262 Edition 5.1 compliant with few extensions. In particular, the mozilla_js_tests cover many Mozilla-specific features which Nashorn will not support. So, some sub-setting and adaptation work is required to use these tests within Nashorn's test framework.
Existing unit tests for the
javax.script API and the
command-line tool can be used against Nashorn as well.
Additional unit/regression tests in the Nashorn repo
These are tests developed by Nashorn developers in the course of implementing features and fixing bugs.
There has been some adaptation work to run these tests under the Nashorn test framework.
Note: These performance tests do not include browser API access (DOM/CSS, et al.) Performance test suites such as Dromaeo do provide such tests, but they are beyond the current scope of Nashorn.
- Compatibility: Nashorn will not implement any feature of the Rhino engine currently in the JDK that is outside of ECMAScript-262.
- Security: Testing required
- Performance/scalability: Testing required
- I18n/L10n: Yes
- Portability: No; Nashorn does not include any native code.
- Documentation: Yes