src/overview.html

Fri, 05 Jun 2015 12:38:53 +0200

author
mhaupt
date
Fri, 05 Jun 2015 12:38:53 +0200
changeset 1398
2f1b9f4daec1
parent 642
360761288b38
child 952
6d5471a497fb
permissions
-rw-r--r--

8080087: Nashorn $ENV.PWD is originally undefined
Summary: On Windows, the PWD environment variable does not exist and cannot be imported in scripting mode, so it is set explicitly.
Reviewed-by: lagergren, sundar

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>,
sundar@642 111 <a href="jdk/nashorn/internal/objects/NativeJavaImporter.html">{@code JavaImporter}</a>,
jlaskey@3 112 <a href="jdk/nashorn/internal/runtime/NativeJavaPackage.html">{@code Packages}.</a>
jlaskey@7 113 </body>

mercurial