jlaskey@3: Nashorn is a runtime environment for programs written in ECMAScript 5.1. jlaskey@3:
jlaskey@3:jlaskey@3: The recommended way to use Nashorn is through the JSR-223 jlaskey@3: "Scripting for the Java Platform" APIs found in the {@link javax.script} package. Usually, you'll obtain a jlaskey@3: {@link javax.script.ScriptEngine} instance for Nashorn using: jlaskey@3:
jlaskey@3: import javax.script.*;
jlaskey@3: ...
jlaskey@3: ScriptEngine nashornEngine = new ScriptEngineManager().getEngineByName("nashorn");
jlaskey@3:
jlaskey@3: and then use it just as you would any other JSR-223 script engine. See
jlaskey@3: {@code jdk.nashorn.api.scripting} package
jlaskey@3: for details.
jlaskey@3: jlaskey@3:
jlaskey@3: In addition to being a 100% ECMAScript 5.1 runtime, Nashorn provides features for interoperability of the ECMAScript jlaskey@3: programs with the Java platform. In general, any Java object put into the script engine's context will be visible from jlaskey@3: the script. In terms of the standard, such Java objects are not considered "native objects", but rather "host objects", jlaskey@3: as defined in section 4.3.8. This distinction allows certain semantical differences in handling them compared to native jlaskey@3: objects. For most purposes, Java objects behave just as native objects do: you can invoke their methods, get and set jlaskey@3: their properties. In most cases, though, you can't add arbitrary properties to them, nor can you remove existing jlaskey@3: properties. jlaskey@3:
jlaskey@3:
jlaskey@3: Native Java arrays and {@link java.util.List}s support indexed access to their elements through the property accessors, jlaskey@3: and {@link java.util.Map}s support both property and element access through both dot and square-bracket property jlaskey@3: accessors, with the difference being that dot operator gives precedence to object properties (its fields and properties jlaskey@3: defined as {@code getXxx} and {@code setXxx} methods) while the square bracket operator gives precedence to map jlaskey@3: elements. Native Java arrays expose the {@code length} property. jlaskey@3:
jlaskey@3:
jlaskey@3: ECMAScript primitive types for number, string, and boolean are represented with {@link java.lang.Number}, jlaskey@3: {@link java.lang.CharSequence}, and {@link java.lang.Boolean} objects. While the most often used number type is jlaskey@3: {@link java.lang.Double} and the most often used string type is {@link java.lang.String}, don't rely on it as various jlaskey@3: internal optimizations cause other subclasses of {@code Number} and internal implementations of {@code CharSequence} to jlaskey@3: be used. jlaskey@3:
jlaskey@3:
jlaskey@3: When a method on a Java object is invoked, the arguments are converted to the formal parameter types of the Java method jlaskey@3: using all allowed ECMAScript conversions. This can be surprising, as in general, conversions from string to number will jlaskey@3: succeed according to Standard's section 9.3 "ToNumber" and so on; string to boolean, number to boolean, Object to jlaskey@3: number, Object to string all work. Note that if the Java method's declared parameter type is {@code java.lang.Object}, jlaskey@3: Nashorn objects are passed without any conversion whatsoever; specifically if the JavaScript value being passed is of jlaskey@3: primitive string type, you can only rely on it being a {@code java.lang.CharSequence}, and if the value is a number, you jlaskey@3: can only rely on it being a {@code java.lang.Number}. If the Java method declared parameter type is more specific (e.g. jlaskey@3: {@code java.lang.String} or {@code java.lang.Double}), then Nashorn will of course ensure the required type is passed. jlaskey@3:
jlaskey@3:
jlaskey@3: As a special extension when invoking Java methods, ECMAScript function objects can be passed in place of an argument jlaskey@3: whose Java type is so-called "single abstract method" or "SAM" type. While this name usually covers single-method jlaskey@3: interfaces, Nashorn is a bit more versatile, and it recognizes a type as a SAM type if all its abstract methods are jlaskey@3: overloads of the same name, and it is either an interface, or it is an abstract class with jlaskey@3: a no-arg constructor. The type itself must be public, while the constructor and the methods can be either public or jlaskey@3: protected. If there are multiple abstract overloads of the same name, the single function will serve as the shared jlaskey@3: implementation for all of them, and additionally it will also override any non-abstract methods of the same name. jlaskey@3: This is done to be consistent with the fact that ECMAScript does not have the concept of overloaded methods. jlaskey@3:
jlaskey@3: