JEP 174: Nashorn JavaScript EngineJEP 174: Nashorn JavaScript EngineOwnerJim LaskeyTypeFeatureScopeJDKStatusClosed / DeliveredRelease8Componentcore-libs / jdk.nashornDiscussionnashorn dash dev at openjdk dot java dot netEffortXLDurationXLReviewed bySundararajan AthijegannathanEndorsed byBrian GoetzCreated2012/11/21 20:00Updated2015/02/13 19:38Issue8046164Summary
Design and implement a new lightweight, high-performance implementation
of JavaScript, and integrate it into the JDK.  The new engine will be
made available to Java applications via the existing javax.script API,
and also more generally via a new command-line tool.
Goals


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.


Non-Goals


Nashorn will only support ECMAScript-262 Edition 5.1.  It will not
support any features of Edition 6, or any non-standard features
provided by other JavaScript implementations.


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.


Motivation
The performance of Rhino has fallen far behind that of other JavaScript
engines. In order to improve performance, at this point Rhino would have
to be rewritten to replace its interpreter with a code generator designed
to fully utilize the JVM.  Rather than undertake a major rewrite of the
very old Rhino code, we have chosen instead to start from scratch.
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.
Description
The Nashorn engine evaluates JavaScript source code in five stages: Lexer
-> parser -> code generation -> loading -> runtime.
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.
Nashorn uses a recursive descent parser based on the ECMAScript 262
language specification.  The parser takes the token stream produced by
the lexer and collects tokens that match the language syntax.  As
syntactic units are recognized, the parser constructs an intermediate
representation (AST/IR) of the JavaScript code.
The code generator takes the AST/IR and generates JVM byte code.  When
executed, this byte code implements the semantics of the original
JavaScript source code.
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 toString and
toNumber, and allocation routines like allocateArray.
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.
The JavaScript objects library includes support for all the standard
JavaScript objects, e.g., Object, Function, Number, String,
Date, Array, RegExp, and so forth.  It also includes functions for
string manipulation, complex math, applying functions, et cetera.
Nashorn uses invokedynamic to implement all of its invocations. If an
invocation has a Java object receiver, Nashorn attempts to bind the call
to an appropriate Java method instead of a JavaScript function.  Nashorn
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
method. The result is completely transparent for calls from JavaScript to
Java.
Java developers can use the javax.script (JSR 223) API to evaluate and
call back into JavaScript code.
Alternatives
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.
Other JavaScript engines, such as V8 and Nitro, provide good performance
but would require a second VM (additional code and memory) and a bridging
API to communicate with Java.
Testing
JCK
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.
Functional/Unit tests
Existing tests include:

test262 (ecmascript.org)
ES5conform

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 jrunscript
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.
Performance tests


Sunspider
JavaScript core engine performance tests (webkit.org)


v8 (Octane) performance tests


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.
Security tests
Nashorn compiles JavaScript source code and generates Java classes. These
classes are loaded by a special class loader.  Nashorn allows Java calls
to be made from JavaScript. Care must be taken to ensure that such
generated classes follow the Java security model. Tests are needed to
ensure that, under a security manager, Nashorn is secure as well. No
additional permissions that are not available to compiled Java class
files should be available to script classes generated by Nashorn.
Impact

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

InstallingContributingSponsoringDevelopers' GuideVulnerabilitiesJDK GA/EA BuildsMailing listsWiki
                      · IRCBylaws · CensusLegalWorkshopJEP ProcessSource codeMercurialGitHubToolsGitjtreg harnessGroups(overview)AdoptionBuildClient LibrariesCompatibility & Specification ReviewCompilerConformanceCore LibrariesGoverning BoardHotSpotIDE Tooling & SupportInternationalizationJMXMembersNetworkingPortersQualitySecurityServiceabilityVulnerabilityWebProjects(overview,
      archive)AmberBabylonCRaCCaciocavalloClosuresCode ToolsCoinCommon VM InterfaceCompiler GrammarDetroitDevelopers' GuideDevice I/ODukeGalahadGraalIcedTeaJDK 7JDK 8JDK 8 UpdatesJDK 9JDK
      (…,
       21,
       22,
       23)JDK UpdatesJavaDoc.NextJigsawKonaKullaLambdaLanaiLeydenLilliputLocale EnhancementLoomMemory Model UpdateMetropolisMission ControlMulti-Language VMNashornNew I/OOpenJFXPanamaPenrosePort: AArch32Port: AArch64Port: BSDPort: HaikuPort: Mac OS XPort: MIPSPort: MobilePort: PowerPC/AIXPort: RISC-VPort: s390xPortolaSCTPShenandoahSkaraSumatraTiered AttributionTsanType AnnotationsValhallaVeronaVisualVMWakefieldZeroZGC

        © 2024 Oracle Corporation and/or its affiliates
        Terms of Use
        ·
        
            License: GPLv2
        · Privacy
        · Trademarks
