* Dynalink is a library for dynamic linking of high-level operations on objects. * These operations include "read a property", @@ -217,6 +218,8 @@ * from B will get a chance to link the call site in A when it encounters the * object from B. * + * @uses jdk.dynalink.linker.GuardingDynamicLinkerExporter + * * @moduleGraph * @since 9 */ diff -r b9c83fbe72e8 -r 27ec0241c724 nashorn/src/jdk.scripting.nashorn.shell/share/classes/module-info.java --- a/nashorn/src/jdk.scripting.nashorn.shell/share/classes/module-info.java Thu Jun 08 16:32:57 2017 +0000 +++ b/nashorn/src/jdk.scripting.nashorn.shell/share/classes/module-info.java Thu Jun 08 23:11:15 2017 +0000 @@ -24,8 +24,17 @@ */ /** - * Nashorn shell module + * Defines Nashorn shell module. + * + *
This module includes the command line tool {@index jjs jjs tool} + * to invoke the Nashorn engine. * + *
-Nashorn is a runtime environment for programs written in ECMAScript 5.1. -
-+ * Provides the implementation of Nashorn script engine and + * the runtime environment for programs written in ECMAScript 5.1. + *+ * Nashorn is a runtime environment for programs written in ECMAScript 5.1. + *
+ * + *Usage
+ * + * The recommended way to use Nashorn is through the + * JSR-223 + * "Scripting for the Java Platform" APIs found in the + * {@link javax.script} package. Usually, you'll obtain a + * {@link javax.script.ScriptEngine} instance for Nashorn using: + *import javax.script.*; ... ScriptEngine nashornEngine = new ScriptEngineManager().getEngineByName("nashorn");-and then use it just as you would any other JSR-223 script engine. See -{@code jdk.nashorn.api.scripting} package -for details. -Compatibility
-Nashorn is 100% compliant with the ECMA-262 Standard, Edition 5.1. It requires a Java Virtual Machine that implements the -JSR-292 "Supporting Dynamically Typed Languages on the Java -Platform" specification (often referred to as "invokedynamic"), as well as the already mentioned JSR-223. -Interoperability with the Java platform
-In addition to being a 100% ECMAScript 5.1 runtime, Nashorn provides features for interoperability of the ECMAScript -programs with the Java platform. In general, any Java object put into the script engine's context will be visible from -the script. In terms of the standard, such Java objects are not considered "native objects", but rather "host objects", -as defined in section 4.3.8. This distinction allows certain semantical differences in handling them compared to native -objects. For most purposes, Java objects behave just as native objects do: you can invoke their methods, get and set -their properties. In most cases, though, you can't add arbitrary properties to them, nor can you remove existing -properties. -Java collection handling
-Native Java arrays and {@link java.util.List}s support indexed access to their elements through the property accessors, -and {@link java.util.Map}s support both property and element access through both dot and square-bracket property -accessors, with the difference being that dot operator gives precedence to object properties (its fields and properties -defined as {@code getXxx} and {@code setXxx} methods) while the square bracket operator gives precedence to map -elements. Native Java arrays expose the {@code length} property. -ECMAScript primitive types
-ECMAScript primitive types for number, string, and boolean are represented with {@link java.lang.Number}, -{@link java.lang.CharSequence}, and {@link java.lang.Boolean} objects. While the most often used number type is -{@link java.lang.Double} and the most often used string type is {@link java.lang.String}, don't rely on it as various -internal optimizations cause other subclasses of {@code Number} and internal implementations of {@code CharSequence} to -be used. -Type conversions
-When a method on a Java object is invoked, the arguments are converted to the formal parameter types of the Java method -using all allowed ECMAScript conversions. This can be surprising, as in general, conversions from string to number will -succeed according to Standard's section 9.3 "ToNumber" and so on; string to boolean, number to boolean, Object to -number, Object to string all work. Note that if the Java method's declared parameter type is {@code java.lang.Object}, -Nashorn objects are passed without any conversion whatsoever; specifically if the JavaScript value being passed is of -primitive string type, you can only rely on it being a {@code java.lang.CharSequence}, and if the value is a number, you -can only rely on it being a {@code java.lang.Number}. If the Java method declared parameter type is more specific (e.g. -{@code java.lang.String} or {@code java.lang.Double}), then Nashorn will of course ensure the required type is passed. -SAM types
-As a special extension when invoking Java methods, ECMAScript function objects can be passed in place of an argument -whose Java type is so-called "single abstract method" or "SAM" type. While this name usually covers single-method -interfaces, Nashorn is a bit more versatile, and it recognizes a type as a SAM type if all its abstract methods are -overloads of the same name, and it is either an interface, or it is an abstract class with -a no-arg constructor. The type itself must be public, while the constructor and the methods can be either public or -protected. If there are multiple abstract overloads of the same name, the single function will serve as the shared -implementation for all of them, and additionally it will also override any non-abstract methods of the same name. -This is done to be consistent with the fact that ECMAScript does not have the concept of overloaded methods. -The {@code Java} object
-Nashorn exposes a non-standard global object named {@code Java} that is the primary API entry point into Java -platform-specific functionality. You can use it to create instances of Java classes, convert from Java arrays to native -arrays and back, and so on. -Other non-standard built-in objects
-In addition to {@code Java}, Nashorn also exposes some other non-standard built-in objects: -{@code JSAdapter}, {@code JavaImporter}, {@code Packages} - -@moduleGraph -@since 9 + * + * and then use it just as you would any other JSR-223 script engine. See + * + * {@code jdk.nashorn.api.scripting} package for details. + *Compatibility
+ * Nashorn is 100% compliant with the + * ECMA-262 Standard, Edition 5.1. + * It requires a Java Virtual Machine that implements the + * + * JSR-292 "Supporting Dynamically Typed Languages on the Java Platform" + * specification (often referred to as "invokedynamic"), as well as + * the already mentioned JSR-223. + * + *Interoperability with the Java platform
+ * + * In addition to being a 100% ECMAScript 5.1 runtime, Nashorn provides features + * for interoperability of the ECMAScript programs with the Java platform. + * In general, any Java object put into the script engine's context will be + * visible from the script. In terms of the standard, such Java objects are not + * considered "native objects", but rather "host objects", as defined in + * section 4.3.8. This distinction allows certain semantical differences + * in handling them compared to native objects. For most purposes, Java objects + * behave just as native objects do: you can invoke their methods, get and set + * their properties. In most cases, though, you can't add arbitrary properties + * to them, nor can you remove existing properties. + * + *Java collection handling
+ * + * Native Java arrays and {@link java.util.List}s support indexed access to + * their elements through the property accessors, and {@link java.util.Map}s + * support both property and element access through both dot and square-bracket + * property accessors, with the difference being that dot operator gives + * precedence to object properties (its fields and properties defined as + * {@code getXxx} and {@code setXxx} methods) while the square bracket + * operator gives precedence to map elements. Native Java arrays expose + * the {@code length} property. + * + *ECMAScript primitive types
+ * + * ECMAScript primitive types for number, string, and boolean are represented + * with {@link java.lang.Number}, {@link java.lang.CharSequence}, and + * {@link java.lang.Boolean} objects. While the most often used number type + * is {@link java.lang.Double} and the most often used string type is + * {@link java.lang.String}, don't rely on it as various internal optimizations + * cause other subclasses of {@code Number} and internal implementations of + * {@code CharSequence} to be used. + * + *Type conversions
+ * + * When a method on a Java object is invoked, the arguments are converted to + * the formal parameter types of the Java method using all allowed ECMAScript + * conversions. This can be surprising, as in general, conversions from string + * to number will succeed according to Standard's section 9.3 "ToNumber" + * and so on; string to boolean, number to boolean, Object to number, + * Object to string all work. Note that if the Java method's declared parameter + * type is {@code java.lang.Object}, Nashorn objects are passed without any + * conversion whatsoever; specifically if the JavaScript value being passed + * is of primitive string type, you can only rely on it being a + * {@code java.lang.CharSequence}, and if the value is a number, you can only + * rely on it being a {@code java.lang.Number}. If the Java method declared + * parameter type is more specific (e.g. {@code java.lang.String} or + * {@code java.lang.Double}), then Nashorn will of course ensure + * the required type is passed. + * + *SAM types
+ * + * As a special extension when invoking Java methods, ECMAScript function + * objects can be passed in place of an argument whose Java type is so-called + * "single abstract method" or "SAM" type. While this name usually covers + * single-method interfaces, Nashorn is a bit more versatile, and it + * recognizes a type as a SAM type if all its abstract methods are + * overloads of the same name, and it is either an interface, or it is an + * abstract class with a no-arg constructor. The type itself must be public, + * while the constructor and the methods can be either public or protected. + * If there are multiple abstract overloads of the same name, the single + * function will serve as the shared implementation for all of them, + * and additionally it will also override any non-abstract methods of + * the same name. This is done to be consistent with the fact that + * ECMAScript does not have the concept of overloaded methods. + * + *The {@code Java} object
+ * + * Nashorn exposes a non-standard global object named {@code Java} that is + * the primary API entry point into Java platform-specific functionality. + * You can use it to create instances of Java classes, convert from Java arrays + * to native arrays and back, and so on. + * + *Other non-standard built-in objects
+ * + * In addition to {@code Java}, Nashorn also exposes some other + * non-standard built-in objects: + * {@code JSAdapter}, {@code JavaImporter}, {@code Packages} + * + * @provides javax.script.ScriptEngineFactory + * @moduleGraph + * @since 9 */ module jdk.scripting.nashorn { requires java.logging;