package-info.java revision 1805:7caf1f762f1d
1/*
2 * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved.
3 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
4 *
5 * This code is free software; you can redistribute it and/or modify it
6 * under the terms of the GNU General Public License version 2 only, as
7 * published by the Free Software Foundation.  Oracle designates this
8 * particular file as subject to the "Classpath" exception as provided
9 * by Oracle in the LICENSE file that accompanied this code.
10 *
11 * This code is distributed in the hope that it will be useful, but WITHOUT
12 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
13 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
14 * version 2 for more details (a copy is included in the LICENSE file that
15 * accompanied this code).
16 *
17 * You should have received a copy of the GNU General Public License version
18 * 2 along with this work; if not, write to the Free Software Foundation,
19 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
20 *
21 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
22 * or visit www.oracle.com if you need additional information or have any
23 * questions.
24 */
25
26/*
27 * This file is available under and governed by the GNU General Public
28 * License version 2 only, as published by the Free Software Foundation.
29 * However, the following notice accompanied the original version of this
30 * file, and Oracle licenses the original version of this file under the BSD
31 * license:
32 */
33/*
34   Copyright 2009-2013 Attila Szegedi
35
36   Licensed under both the Apache License, Version 2.0 (the "Apache License")
37   and the BSD License (the "BSD License"), with licensee being free to
38   choose either of the two at their discretion.
39
40   You may not use this file except in compliance with either the Apache
41   License or the BSD License.
42
43   If you choose to use this file in compliance with the Apache License, the
44   following notice applies to you:
45
46       You may obtain a copy of the Apache License at
47
48           http://www.apache.org/licenses/LICENSE-2.0
49
50       Unless required by applicable law or agreed to in writing, software
51       distributed under the License is distributed on an "AS IS" BASIS,
52       WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
53       implied. See the License for the specific language governing
54       permissions and limitations under the License.
55
56   If you choose to use this file in compliance with the BSD License, the
57   following notice applies to you:
58
59       Redistribution and use in source and binary forms, with or without
60       modification, are permitted provided that the following conditions are
61       met:
62       * Redistributions of source code must retain the above copyright
63         notice, this list of conditions and the following disclaimer.
64       * Redistributions in binary form must reproduce the above copyright
65         notice, this list of conditions and the following disclaimer in the
66         documentation and/or other materials provided with the distribution.
67       * Neither the name of the copyright holder nor the names of
68         contributors may be used to endorse or promote products derived from
69         this software without specific prior written permission.
70
71       THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
72       IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
73       TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
74       PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL COPYRIGHT HOLDER
75       BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
76       CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
77       SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
78       BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
79       WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
80       OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
81       ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
82*/
83
84/**
85 * <p>
86 * Dynalink is a library for dynamic linking of high-level operations on objects.
87 * These operations include "read a property",
88 * "write a property", "invoke a function" and so on. Dynalink is primarily
89 * useful for implementing programming languages where at least some expressions
90 * have dynamic types (that is, types that can not be decided statically), and
91 * the operations on dynamic types are expressed as
92 * {@link java.lang.invoke.CallSite call sites}. These call sites will be
93 * linked to appropriate target {@link java.lang.invoke.MethodHandle method handles}
94 * at run time based on actual types of the values the expressions evaluated to.
95 * These can change between invocations, necessitating relinking the call site
96 * multiple times to accommodate new types; Dynalink handles all that and more.
97 * <p>
98 * Dynalink supports implementation of programming languages with object models
99 * that differ (even radically) from the JVM's class-based model and have their
100 * custom type conversions.
101 * <p>
102 * Dynalink is closely related to, and relies on, the {@link java.lang.invoke}
103 * package.
104 * <p>
105 *
106 * While {@link java.lang.invoke} provides a low level API for dynamic linking
107 * of {@code invokedynamic} call sites, it does not provide a way to express
108 * higher level operations on objects, nor methods that implement them. These
109 * operations are the usual ones in object-oriented environments: property
110 * access, access of elements of collections, invocation of methods and
111 * constructors (potentially with multiple dispatch, e.g. link- and run-time
112 * equivalents of Java overloaded method resolution). These are all functions
113 * that are normally desired in a language on the JVM. If a language is
114 * statically typed and its type system matches that of the JVM, it can
115 * accomplish this with use of the usual invocation, field access, etc.
116 * instructions (e.g. {@code invokevirtual}, {@code getfield}). However, if the
117 * language is dynamic (hence, types of some expressions are not known until
118 * evaluated at run time), or its object model or type system don't match
119 * closely that of the JVM, then it should use {@code invokedynamic} call sites
120 * instead and let Dynalink manage them.
121 * <h2>Example</h2>
122 * Dynalink is probably best explained by an example showing its use. Let's
123 * suppose you have a program in a language where you don't have to declare the
124 * type of an object and you want to access a property on it:
125 * <pre>
126 * var color = obj.color;
127 * </pre>
128 * If you generated a Java class to represent the above one-line program, its
129 * bytecode would look something like this:
130 * <pre>
131 * aload 2 // load "obj" on stack
132 * invokedynamic "GET:PROPERTY:color"(Object)Object // invoke property getter on object of unknown type
133 * astore 3 // store the return value into local variable "color"
134 * </pre>
135 * In order to link the {@code invokedynamic} instruction, we need a bootstrap
136 * method. A minimalist bootstrap method with Dynalink could look like this:
137 * <pre>
138 * import java.lang.invoke.*;
139 * import jdk.dynalink.*;
140 * import jdk.dynalink.support.*;
141 *
142 * class MyLanguageRuntime {
143 *     private static final DynamicLinker dynamicLinker = new DynamicLinkerFactory().createLinker();
144 *
145 *     public static CallSite bootstrap(MethodHandles.Lookup lookup, String name, MethodType type) {
146 *         return dynamicLinker.link(
147 *             new SimpleRelinkableCallSite(
148 *                 new CallSiteDescriptor(lookup, parseOperation(name), type)));
149 *     }
150 *
151 *     private static Operation parseOperation(String name) {
152 *         ...
153 *     }
154 * }
155 * </pre>
156 * There are several objects of significance in the above code snippet:
157 * <ul>
158 * <li>{@link jdk.dynalink.DynamicLinker} is the main object in Dynalink, it
159 * coordinates the linking of call sites to method handles that implement the
160 * operations named in them. It is configured and created using a
161 * {@link jdk.dynalink.DynamicLinkerFactory}.</li>
162 * <li>When the bootstrap method is invoked, it needs to create a
163 * {@link java.lang.invoke.CallSite} object. In Dynalink, these call sites need
164 * to additionally implement the {@link jdk.dynalink.RelinkableCallSite}
165 * interface. "Relinkable" here alludes to the fact that if the call site
166 * encounters objects of different types at run time, its target will be changed
167 * to a method handle that can perform the operation on the newly encountered
168 * type. {@link jdk.dynalink.support.SimpleRelinkableCallSite} and
169 * {@link jdk.dynalink.support.ChainedCallSite} (not used in the above example)
170 * are two implementations already provided by the library.</li>
171 * <li>Dynalink uses {@link jdk.dynalink.CallSiteDescriptor} objects to
172 * preserve the parameters to the bootstrap method: the lookup and the method type,
173 * as it will need them whenever it needs to relink a call site.</li>
174 * <li>Dynalink uses {@link jdk.dynalink.Operation} objects to express
175 * dynamic operations. It does not prescribe how would you encode the operations
176 * in your call site, though. That is why in the above example the
177 * {@code parseOperation} function is left empty, and you would be expected to
178 * provide the code to parse the string {@code "GET:PROPERTY:color"}
179 * in the call site's name into a named property getter operation object as
180 * {@code StandardOperation.GET.withNamespace(StandardNamespace.PROPERTY).named("color")}.
181 * </ul>
182 * <p>What can you already do with the above setup? {@code DynamicLinkerFactory}
183 * by default creates a {@code DynamicLinker} that can link Java objects with the
184 * usual Java semantics. If you have these three simple classes:
185 * <pre>
186 * public class A {
187 *     public String color;
188 *     public A(String color) { this.color = color; }
189 * }
190 *
191 * public class B {
192 *     private String color;
193 *     public B(String color) { this.color = color; }
194 *     public String getColor() { return color; }
195 * }
196 *
197 * public class C {
198 *     private int color;
199 *     public C(int color) { this.color = color; }
200 *     public int getColor() { return color; }
201 * }
202 * </pre>
203 * and you somehow create their instances and pass them to your call site in your
204 * programming language:
205 * <pre>
206 * for each(var obj in [new A("red"), new B("green"), new C(0x0000ff)]) {
207 *     print(obj.color);
208 * }
209 * </pre>
210 * then on first invocation, Dynalink will link the {@code .color} getter
211 * operation to a field getter for {@code A.color}, on second invocation it will
212 * relink it to {@code B.getColor()} returning a {@code String}, and finally on
213 * third invocation it will relink it to {@code C.getColor()} returning an {@code int}.
214 * The {@code SimpleRelinkableCallSite} we used above only remembers the linkage
215 * for the last encountered type (it implements what is known as a <i>monomorphic
216 * inline cache</i>). Another already provided implementation,
217 * {@link jdk.dynalink.support.ChainedCallSite} will remember linkages for
218 * several different types (it is a <i>polymorphic inline cache</i>) and is
219 * probably a better choice in serious applications.
220 * <h2>Dynalink and bytecode creation</h2>
221 * {@code CallSite} objects are usually created as part of bootstrapping
222 * {@code invokedynamic} instructions in bytecode. Hence, Dynalink is typically
223 * used as part of language runtimes that compile programs into Java
224 * {@code .class} bytecode format. Dynalink does not address the aspects of
225 * either creating bytecode classes or loading them into the JVM. That said,
226 * Dynalink can also be used without bytecode compilation (e.g. in language
227 * interpreters) by creating {@code CallSite} objects explicitly and associating
228 * them with representations of dynamic operations in the interpreted program
229 * (e.g. a typical representation would be some node objects in a syntax tree).
230 * <h2>Available operations</h2>
231 * Dynalink defines several standard operations in its
232 * {@link jdk.dynalink.StandardOperation} class. The linker for Java
233 * objects can link all of these operations, and you are encouraged to at
234 * minimum support and use these operations in your language too. The
235 * standard operations {@code GET} and {@code SET} need to be combined with
236 * at least one {@link jdk.dynalink.Namespace} to be useful, e.g. to express a
237 * property getter, you'd use {@code StandardOperation.GET.withNamespace(StandardNamespace.PROPERTY)}.
238 * Dynalink defines three standard namespaces in the {@link jdk.dynalink.StandardNamespace} class.
239 * To associate a fixed name with an operation, you can use
240 * {@link jdk.dynalink.NamedOperation} as in the previous example:
241 * {@code StandardOperation.GET.withNamespace(StandardNamespace.PROPERTY).named("color")}
242 * expresses a getter for the property named "color".
243 * <h2>Operations on multiple namespaces</h2>
244 * Some languages might not have separate namespaces on objects for
245 * properties, elements, and methods, and a source language construct might
246 * address several of them at once. Dynalink supports specifying multiple
247 * {@link jdk.dynalink.Namespace} objects with {@link jdk.dynalink.NamespaceOperation}.
248 * <h2>Language-specific linkers</h2>
249 * Languages that define their own object model different than the JVM
250 * class-based model and/or use their own type conversions will need to create
251 * their own language-specific linkers. See the {@link jdk.dynalink.linker}
252 * package and specifically the {@link jdk.dynalink.linker.GuardingDynamicLinker}
253 * interface to get started.
254 * <h2>Dynalink and Java objects</h2>
255 * The {@code DynamicLinker} objects created by {@code DynamicLinkerFactory} by
256 * default contain an internal instance of
257 * {@code BeansLinker}, which is a language-specific linker
258 * that implements the usual Java semantics for all of the above operations and
259 * can link any Java object that no other language-specific linker has managed
260 * to link. This way, all language runtimes have built-in interoperability with
261 * ordinary Java objects. See {@link jdk.dynalink.beans.BeansLinker} for details
262 * on how it links the various operations.
263 * <h2>Cross-language interoperability</h2>
264 * A {@code DynamicLinkerFactory} can be configured with a
265 * {@link jdk.dynalink.DynamicLinkerFactory#setClassLoader(ClassLoader) class
266 * loader}. It will try to instantiate all
267 * {@link jdk.dynalink.linker.GuardingDynamicLinkerExporter} classes visible to
268 * that class loader and compose the linkers they provide into the
269 * {@code DynamicLinker} it creates. This allows for interoperability between
270 * languages: if you have two language runtimes A and B deployed in your JVM and
271 * they export their linkers through the above mechanism, language runtime A
272 * will have a language-specific linker instance from B and vice versa inside
273 * their {@code DynamicLinker} objects. This means that if an object from
274 * language runtime B gets passed to code from language runtime A, the linker
275 * from B will get a chance to link the call site in A when it encounters the
276 * object from B.
277 */
278package jdk.dynalink;
279