Wed, 24 Jul 2013 08:25:04 -0300
Merge
jlaskey@3 | 1 | <!-- |
jlaskey@7 | 2 | Copyright (c) 2010, 2013, Oracle and/or its affiliates. All rights reserved. |
jlaskey@3 | 3 | DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. |
jlaskey@3 | 4 | |
jlaskey@3 | 5 | This code is free software; you can redistribute it and/or modify it |
jlaskey@3 | 6 | under the terms of the GNU General Public License version 2 only, as |
jlaskey@3 | 7 | published by the Free Software Foundation. Oracle designates this |
jlaskey@3 | 8 | particular file as subject to the "Classpath" exception as provided |
jlaskey@3 | 9 | by Oracle in the LICENSE file that accompanied this code. |
jlaskey@3 | 10 | |
jlaskey@3 | 11 | This code is distributed in the hope that it will be useful, but WITHOUT |
jlaskey@3 | 12 | ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or |
jlaskey@3 | 13 | FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License |
jlaskey@3 | 14 | version 2 for more details (a copy is included in the LICENSE file that |
jlaskey@3 | 15 | accompanied this code). |
jlaskey@3 | 16 | |
jlaskey@3 | 17 | You should have received a copy of the GNU General Public License version |
jlaskey@3 | 18 | 2 along with this work; if not, write to the Free Software Foundation, |
jlaskey@3 | 19 | Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. |
jlaskey@3 | 20 | |
jlaskey@3 | 21 | Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA |
jlaskey@3 | 22 | or visit www.oracle.com if you need additional information or have any |
jlaskey@3 | 23 | questions. |
jlaskey@3 | 24 | --> |
jlaskey@3 | 25 | <body> |
jlaskey@3 | 26 | <p> |
jlaskey@3 | 27 | Nashorn is a runtime environment for programs written in ECMAScript 5.1. |
jlaskey@3 | 28 | </p> |
jlaskey@3 | 29 | <h1>Usage</h1> |
jlaskey@3 | 30 | <p> |
jlaskey@3 | 31 | The recommended way to use Nashorn is through the <a href="http://jcp.org/en/jsr/detail?id=223" target="_top">JSR-223 |
jlaskey@3 | 32 | "Scripting for the Java Platform"</a> APIs found in the {@link javax.script} package. Usually, you'll obtain a |
jlaskey@3 | 33 | {@link javax.script.ScriptEngine} instance for Nashorn using: |
jlaskey@3 | 34 | <pre> |
jlaskey@3 | 35 | import javax.script.*; |
jlaskey@3 | 36 | ... |
jlaskey@3 | 37 | ScriptEngine nashornEngine = new ScriptEngineManager().getEngineByName("nashorn"); |
jlaskey@3 | 38 | </pre> |
jlaskey@3 | 39 | and then use it just as you would any other JSR-223 script engine. See |
jlaskey@3 | 40 | <a href="jdk/nashorn/api/scripting/package-summary.html">{@code jdk.nashorn.api.scripting}</a> package |
jlaskey@3 | 41 | for details. |
jlaskey@3 | 42 | <p> |
jlaskey@3 | 43 | <h1>Compatibility</h1> |
jlaskey@3 | 44 | Nashorn is 100% compliant with the <a href="http://www.ecma-international.org/publications/standards/Ecma-262.htm" |
jlaskey@3 | 45 | target="_top">ECMA-262 Standard, Edition 5.1</a>. It requires a Java Virtual Machine that implements the |
jlaskey@3 | 46 | <a href="http://jcp.org/en/jsr/detail?id=292" target="_top">JSR-292 "Supporting Dynamically Typed Languages on the Java |
jlaskey@3 | 47 | Platform"</a> specification (often referred to as "invokedynamic"), as well as the already mentioned JSR-223. |
jlaskey@3 | 48 | <h1>Interoperability with the Java platform</h1> |
jlaskey@3 | 49 | <p> |
jlaskey@3 | 50 | In addition to being a 100% ECMAScript 5.1 runtime, Nashorn provides features for interoperability of the ECMAScript |
jlaskey@3 | 51 | programs with the Java platform. In general, any Java object put into the script engine's context will be visible from |
jlaskey@3 | 52 | the script. In terms of the standard, such Java objects are not considered "native objects", but rather "host objects", |
jlaskey@3 | 53 | as defined in section 4.3.8. This distinction allows certain semantical differences in handling them compared to native |
jlaskey@3 | 54 | objects. For most purposes, Java objects behave just as native objects do: you can invoke their methods, get and set |
jlaskey@3 | 55 | their properties. In most cases, though, you can't add arbitrary properties to them, nor can you remove existing |
jlaskey@3 | 56 | properties. |
jlaskey@3 | 57 | <p> |
jlaskey@3 | 58 | <h2>Java collection handling</h2> |
jlaskey@3 | 59 | <p> |
jlaskey@3 | 60 | Native Java arrays and {@link java.util.List}s support indexed access to their elements through the property accessors, |
jlaskey@3 | 61 | and {@link java.util.Map}s support both property and element access through both dot and square-bracket property |
jlaskey@3 | 62 | accessors, with the difference being that dot operator gives precedence to object properties (its fields and properties |
jlaskey@3 | 63 | defined as {@code getXxx} and {@code setXxx} methods) while the square bracket operator gives precedence to map |
jlaskey@3 | 64 | elements. Native Java arrays expose the {@code length} property. |
jlaskey@3 | 65 | <p> |
jlaskey@3 | 66 | <h2>ECMAScript primitive types</h2> |
jlaskey@3 | 67 | <p> |
jlaskey@3 | 68 | ECMAScript primitive types for number, string, and boolean are represented with {@link java.lang.Number}, |
jlaskey@3 | 69 | {@link java.lang.CharSequence}, and {@link java.lang.Boolean} objects. While the most often used number type is |
jlaskey@3 | 70 | {@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 | 71 | internal optimizations cause other subclasses of {@code Number} and internal implementations of {@code CharSequence} to |
jlaskey@3 | 72 | be used. |
jlaskey@3 | 73 | <p> |
jlaskey@3 | 74 | <h2>Type conversions</h2> |
jlaskey@3 | 75 | <p> |
jlaskey@3 | 76 | When a method on a Java object is invoked, the arguments are converted to the formal parameter types of the Java method |
jlaskey@3 | 77 | using all allowed ECMAScript conversions. This can be surprising, as in general, conversions from string to number will |
jlaskey@3 | 78 | succeed according to Standard's section 9.3 "ToNumber" and so on; string to boolean, number to boolean, Object to |
jlaskey@3 | 79 | number, Object to string all work. Note that if the Java method's declared parameter type is {@code java.lang.Object}, |
jlaskey@3 | 80 | Nashorn objects are passed without any conversion whatsoever; specifically if the JavaScript value being passed is of |
jlaskey@3 | 81 | 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 | 82 | 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 | 83 | {@code java.lang.String} or {@code java.lang.Double}), then Nashorn will of course ensure the required type is passed. |
jlaskey@3 | 84 | <p> |
jlaskey@3 | 85 | <h2>SAM types</h2> |
jlaskey@3 | 86 | <p> |
jlaskey@3 | 87 | As a special extension when invoking Java methods, ECMAScript function objects can be passed in place of an argument |
jlaskey@3 | 88 | whose Java type is so-called "single abstract method" or "SAM" type. While this name usually covers single-method |
jlaskey@3 | 89 | interfaces, Nashorn is a bit more versatile, and it recognizes a type as a SAM type if all its abstract methods are |
jlaskey@3 | 90 | overloads of the same name, and it is either an interface, or it is an abstract class with |
jlaskey@3 | 91 | a no-arg constructor. The type itself must be public, while the constructor and the methods can be either public or |
jlaskey@3 | 92 | protected. If there are multiple abstract overloads of the same name, the single function will serve as the shared |
jlaskey@3 | 93 | implementation for all of them, <em>and additionally it will also override any non-abstract methods of the same name</em>. |
jlaskey@3 | 94 | This is done to be consistent with the fact that ECMAScript does not have the concept of overloaded methods. |
jlaskey@3 | 95 | <p> |
jlaskey@3 | 96 | <h2>The {@code Java} object</h2> |
jlaskey@3 | 97 | Nashorn exposes a non-standard global object named {@code Java} that is the primary API entry point into Java |
jlaskey@3 | 98 | platform-specific functionality. You can use it to create instances of Java classes, convert from Java arrays to native |
jlaskey@3 | 99 | arrays and back, and so on. The methods on the objects are directly implemented by public static methods on the class |
jlaskey@3 | 100 | <a href="jdk/nashorn/internal/objects/NativeJava.html">{@code NativeJava}</a>, see that class for details on what |
jlaskey@3 | 101 | functionality is available. |
jlaskey@3 | 102 | <h2>Representations of Java types</h2> |
jlaskey@3 | 103 | The method <a href="jdk/nashorn/internal/objects/NativeJava.html#type(java.lang.Object,%20java.lang.Object)"> |
jlaskey@3 | 104 | {@code Java.type(typeName)}</a> takes a name of a type, and returns an object representing a Java type. You can |
jlaskey@3 | 105 | use that object to both create new instances of Java classes, as well as to access static fields and methods on them. |
jlaskey@3 | 106 | The type object is distinct from the {@code java.lang.Class} object, which represents the reflective run-time type |
jlaskey@3 | 107 | identity and doesn't carry i.e. static members. Again, see the link for {@code NativeJava} above for details. |
jlaskey@3 | 108 | <h2>Other non-standard built-in objects</h2> |
jlaskey@3 | 109 | In addition to {@code Java}, Nashorn also exposes some other non-standard built-in objects: |
jlaskey@3 | 110 | <a href="jdk/nashorn/internal/objects/NativeJSAdapter.html">{@code JSAdapter}</a>, |
jlaskey@3 | 111 | <a href="jdk/nashorn/internal/objects/NativeJavaImporter.html">{@code JavaImporter}, |
jlaskey@3 | 112 | <a href="jdk/nashorn/internal/runtime/NativeJavaPackage.html">{@code Packages}.</a> |
jlaskey@7 | 113 | </body> |