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  * <p>
  28  * Dynalink is a library for dynamic linking of high-level operations on objects.
  29  * These operations include "read a property",
  30  * "write a property", "invoke a function" and so on. Dynalink is primarily
  31  * useful for implementing programming languages where at least some expressions
  32  * have dynamic types (that is, types that can not be decided statically), and
  33  * the operations on dynamic types are expressed as
  34  * {@link java.lang.invoke.CallSite call sites}. These call sites will be
  35  * linked to appropriate target {@link java.lang.invoke.MethodHandle method handles}
  36  * at run time based on actual types of the values the expressions evaluated to.
  37  * These can change between invocations, necessitating relinking the call site
  38  * multiple times to accommodate new types; Dynalink handles all that and more.
  39  * <p>
  40  * Dynalink supports implementation of programming languages with object models
  41  * that differ (even radically) from the JVM's class-based model and have their
  42  * custom type conversions.
  43  * <p>
  44  * Dynalink is closely related to, and relies on, the {@link java.lang.invoke}
  45  * package.
  46  * <p>
  47  *
  48  * While {@link java.lang.invoke} provides a low level API for dynamic linking
  49  * of {@code invokedynamic} call sites, it does not provide a way to express
  50  * higher level operations on objects, nor methods that implement them. These
  51  * operations are the usual ones in object-oriented environments: property
  52  * access, access of elements of collections, invocation of methods and
  53  * constructors (potentially with multiple dispatch, e.g. link- and run-time
  54  * equivalents of Java overloaded method resolution). These are all functions
  55  * that are normally desired in a language on the JVM. If a language is
  56  * statically typed and its type system matches that of the JVM, it can
  57  * accomplish this with use of the usual invocation, field access, etc.
  58  * instructions (e.g. {@code invokevirtual}, {@code getfield}). However, if the
  59  * language is dynamic (hence, types of some expressions are not known until
  60  * evaluated at run time), or its object model or type system don't match
  61  * closely that of the JVM, then it should use {@code invokedynamic} call sites
  62  * instead and let Dynalink manage them.
  63  * <h2>Example</h2>
  64  * Dynalink is probably best explained by an example showing its use. Let's
  65  * suppose you have a program in a language where you don't have to declare the
  66  * type of an object and you want to access a property on it:
  67  * <pre>
  68  * var color = obj.color;
  69  * </pre>
  70  * If you generated a Java class to represent the above one-line program, its
  71  * bytecode would look something like this:
  72  * <pre>
  73  * aload 2 // load "obj" on stack
  74  * invokedynamic "GET:PROPERTY:color"(Object)Object // invoke property getter on object of unknown type
  75  * astore 3 // store the return value into local variable "color"
  76  * </pre>
  77  * In order to link the {@code invokedynamic} instruction, we need a bootstrap
  78  * method. A minimalist bootstrap method with Dynalink could look like this:
  79  * <pre>
  80  * import java.lang.invoke.*;
  81  * import jdk.dynalink.*;
  82  * import jdk.dynalink.support.*;
  83  *
  84  * class MyLanguageRuntime {
  85  *     private static final DynamicLinker dynamicLinker = new DynamicLinkerFactory().createLinker();
  86  *
  87  *     public static CallSite bootstrap(MethodHandles.Lookup lookup, String name, MethodType type) {
  88  *         return dynamicLinker.link(
  89  *             new SimpleRelinkableCallSite(
  90  *                 new CallSiteDescriptor(lookup, parseOperation(name), type)));
  91  *     }
  92  *
  93  *     private static Operation parseOperation(String name) {
  94  *         ...
  95  *     }
  96  * }
  97  * </pre>
  98  * There are several objects of significance in the above code snippet:
  99  * <ul>
 100  * <li>{@link jdk.dynalink.DynamicLinker} is the main object in Dynalink, it
 101  * coordinates the linking of call sites to method handles that implement the
 102  * operations named in them. It is configured and created using a
 103  * {@link jdk.dynalink.DynamicLinkerFactory}.</li>
 104  * <li>When the bootstrap method is invoked, it needs to create a
 105  * {@link java.lang.invoke.CallSite} object. In Dynalink, these call sites need
 106  * to additionally implement the {@link jdk.dynalink.RelinkableCallSite}
 107  * interface. "Relinkable" here alludes to the fact that if the call site
 108  * encounters objects of different types at run time, its target will be changed
 109  * to a method handle that can perform the operation on the newly encountered
 110  * type. {@link jdk.dynalink.support.SimpleRelinkableCallSite} and
 111  * {@link jdk.dynalink.support.ChainedCallSite} (not used in the above example)
 112  * are two implementations already provided by the library.</li>
 113  * <li>Dynalink uses {@link jdk.dynalink.CallSiteDescriptor} objects to
 114  * preserve the parameters to the bootstrap method: the lookup and the method type,
 115  * as it will need them whenever it needs to relink a call site.</li>
 116  * <li>Dynalink uses {@link jdk.dynalink.Operation} objects to express
 117  * dynamic operations. It does not prescribe how would you encode the operations
 118  * in your call site, though. That is why in the above example the
 119  * {@code parseOperation} function is left empty, and you would be expected to
 120  * provide the code to parse the string {@code "GET:PROPERTY:color"}
 121  * in the call site's name into a named property getter operation object as
 122  * {@code StandardOperation.GET.withNamespace(StandardNamespace.PROPERTY).named("color")}.
 123  * </ul>
 124  * <p>What can you already do with the above setup? {@code DynamicLinkerFactory}
 125  * by default creates a {@code DynamicLinker} that can link Java objects with the
 126  * usual Java semantics. If you have these three simple classes:
 127  * <pre>
 128  * public class A {
 129  *     public String color;
 130  *     public A(String color) { this.color = color; }
 131  * }
 132  *
 133  * public class B {
 134  *     private String color;
 135  *     public B(String color) { this.color = color; }
 136  *     public String getColor() { return color; }
 137  * }
 138  *
 139  * public class C {
 140  *     private int color;
 141  *     public C(int color) { this.color = color; }
 142  *     public int getColor() { return color; }
 143  * }
 144  * </pre>
 145  * and you somehow create their instances and pass them to your call site in your
 146  * programming language:
 147  * <pre>
 148  * for each(var obj in [new A("red"), new B("green"), new C(0x0000ff)]) {
 149  *     print(obj.color);
 150  * }
 151  * </pre>
 152  * then on first invocation, Dynalink will link the {@code .color} getter
 153  * operation to a field getter for {@code A.color}, on second invocation it will
 154  * relink it to {@code B.getColor()} returning a {@code String}, and finally on
 155  * third invocation it will relink it to {@code C.getColor()} returning an {@code int}.
 156  * The {@code SimpleRelinkableCallSite} we used above only remembers the linkage
 157  * for the last encountered type (it implements what is known as a <i>monomorphic
 158  * inline cache</i>). Another already provided implementation,
 159  * {@link jdk.dynalink.support.ChainedCallSite} will remember linkages for
 160  * several different types (it is a <i>polymorphic inline cache</i>) and is
 161  * probably a better choice in serious applications.
 162  * <h2>Dynalink and bytecode creation</h2>
 163  * {@code CallSite} objects are usually created as part of bootstrapping
 164  * {@code invokedynamic} instructions in bytecode. Hence, Dynalink is typically
 165  * used as part of language runtimes that compile programs into Java
 166  * {@code .class} bytecode format. Dynalink does not address the aspects of
 167  * either creating bytecode classes or loading them into the JVM. That said,
 168  * Dynalink can also be used without bytecode compilation (e.g. in language
 169  * interpreters) by creating {@code CallSite} objects explicitly and associating
 170  * them with representations of dynamic operations in the interpreted program
 171  * (e.g. a typical representation would be some node objects in a syntax tree).
 172  * <h2>Available operations</h2>
 173  * Dynalink defines several standard operations in its
 174  * {@link jdk.dynalink.StandardOperation} class. The linker for Java
 175  * objects can link all of these operations, and you are encouraged to at
 176  * minimum support and use these operations in your language too. The
 177  * standard operations {@code GET} and {@code SET} need to be combined with
 178  * at least one {@link jdk.dynalink.Namespace} to be useful, e.g. to express a
 179  * property getter, you'd use {@code StandardOperation.GET.withNamespace(StandardNamespace.PROPERTY)}.
 180  * Dynalink defines three standard namespaces in the {@link jdk.dynalink.StandardNamespace} class.
 181  * To associate a fixed name with an operation, you can use
 182  * {@link jdk.dynalink.NamedOperation} as in the previous example:
 183  * {@code StandardOperation.GET.withNamespace(StandardNamespace.PROPERTY).named("color")}
 184  * expresses a getter for the property named "color".
 185  * <h2>Operations on multiple namespaces</h2>
 186  * Some languages might not have separate namespaces on objects for
 187  * properties, elements, and methods, and a source language construct might
 188  * address several of them at once. Dynalink supports specifying multiple
 189  * {@link jdk.dynalink.Namespace} objects with {@link jdk.dynalink.NamespaceOperation}.
 190  * <h2>Language-specific linkers</h2>
 191  * Languages that define their own object model different than the JVM
 192  * class-based model and/or use their own type conversions will need to create
 193  * their own language-specific linkers. See the {@link jdk.dynalink.linker}
 194  * package and specifically the {@link jdk.dynalink.linker.GuardingDynamicLinker}
 195  * interface to get started.
 196  * <h2>Dynalink and Java objects</h2>
 197  * The {@code DynamicLinker} objects created by {@code DynamicLinkerFactory} by
 198  * default contain an internal instance of
 199  * {@code BeansLinker}, which is a language-specific linker
 200  * that implements the usual Java semantics for all of the above operations and
 201  * can link any Java object that no other language-specific linker has managed
 202  * to link. This way, all language runtimes have built-in interoperability with
 203  * ordinary Java objects. See {@link jdk.dynalink.beans.BeansLinker} for details
 204  * on how it links the various operations.
 205  * <h2>Cross-language interoperability</h2>
 206  * A {@code DynamicLinkerFactory} can be configured with a
 207  * {@link jdk.dynalink.DynamicLinkerFactory#setClassLoader(ClassLoader) class
 208  * loader}. It will try to instantiate all
 209  * {@link jdk.dynalink.linker.GuardingDynamicLinkerExporter} classes visible to
 210  * that class loader and compose the linkers they provide into the
 211  * {@code DynamicLinker} it creates. This allows for interoperability between
 212  * languages: if you have two language runtimes A and B deployed in your JVM and
 213  * they export their linkers through the above mechanism, language runtime A
 214  * will have a language-specific linker instance from B and vice versa inside
 215  * their {@code DynamicLinker} objects. This means that if an object from
 216  * language runtime B gets passed to code from language runtime A, the linker
 217  * from B will get a chance to link the call site in A when it encounters the
 218  * object from B.
 219  *
 220  * @moduleGraph
 221  * @since 9
 222  */
 223 module jdk.dynalink {
 224     requires java.logging;
 225 
 226     exports jdk.dynalink;
 227     exports jdk.dynalink.beans;
 228     exports jdk.dynalink.linker;
 229     exports jdk.dynalink.linker.support;
 230     exports jdk.dynalink.support;
 231 
 232     uses jdk.dynalink.linker.GuardingDynamicLinkerExporter;
 233 }
 234