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