* <p>

 * Dynalink is a library for dynamic linking of high-level operations on objects.

 * These operations include "read a property",

 * "write a property", "invoke a function" and so on. Dynalink is primarily

 * useful for implementing programming languages where at least some expressions

 * have dynamic types (that is, types that can not be decided statically), and

 * the operations on dynamic types are expressed as

 * {@link java.lang.invoke.CallSite call sites}. These call sites will be

 * linked to appropriate target {@link java.lang.invoke.MethodHandle method handles}

 * at run time based on actual types of the values the expressions evaluated to.

 * These can change between invocations, necessitating relinking the call site

 * multiple times to accommodate new types; Dynalink handles all that and more.

 * <p>

 * Dynalink supports implementation of programming languages with object models

 * that differ (even radically) from the JVM's class-based model and have their

 * custom type conversions.

 * <p>

 * Dynalink is closely related to, and relies on, the {@link java.lang.invoke}

 * package.

 * <p>

 *

 * While {@link java.lang.invoke} provides a low level API for dynamic linking

 * of {@code invokedynamic} call sites, it does not provide a way to express

 * higher level operations on objects, nor methods that implement them. These

 * operations are the usual ones in object-oriented environments: property

 * access, access of elements of collections, invocation of methods and

 * constructors (potentially with multiple dispatch, e.g. link- and run-time

 * equivalents of Java overloaded method resolution). These are all functions

 * that are normally desired in a language on the JVM. If a language is

 * statically typed and its type system matches that of the JVM, it can

 * accomplish this with use of the usual invocation, field access, etc.

 * instructions (e.g. {@code invokevirtual}, {@code getfield}). However, if the

 * language is dynamic (hence, types of some expressions are not known until

 * evaluated at run time), or its object model or type system don't match

 * closely that of the JVM, then it should use {@code invokedynamic} call sites

 * instead and let Dynalink manage them.

 * <h2>Example</h2>

 * Dynalink is probably best explained by an example showing its use. Let's

 * suppose you have a program in a language where you don't have to declare the

 * type of an object and you want to access a property on it:

 * <pre>

 * var color = obj.color;

 * </pre>

 * If you generated a Java class to represent the above one-line program, its

 * bytecode would look something like this:

 * <pre>

 * aload 2 // load "obj" on stack

 * invokedynamic "GET:PROPERTY:color"(Object)Object // invoke property getter on object of unknown type

 * astore 3 // store the return value into local variable "color"

 * </pre>

 * In order to link the {@code invokedynamic} instruction, we need a bootstrap

 * method. A minimalist bootstrap method with Dynalink could look like this:

 * <pre>

 * import java.lang.invoke.*;

 * import jdk.dynalink.*;

 * import jdk.dynalink.support.*;

 *

 * class MyLanguageRuntime {

 *     private static final DynamicLinker dynamicLinker = new DynamicLinkerFactory().createLinker();

 *

 *     public static CallSite bootstrap(MethodHandles.Lookup lookup, String name, MethodType type) {

 *         return dynamicLinker.link(

 *             new SimpleRelinkableCallSite(

 *                 new CallSiteDescriptor(lookup, parseOperation(name), type)));

 *     }

 *

 *     private static Operation parseOperation(String name) {

 *         ...

 *     }

 * }

 * </pre>

 * There are several objects of significance in the above code snippet:

 * <ul>

 * <li>{@link jdk.dynalink.DynamicLinker} is the main object in Dynalink, it

 * coordinates the linking of call sites to method handles that implement the

 * operations named in them. It is configured and created using a

 * {@link jdk.dynalink.DynamicLinkerFactory}.</li>

 * <li>When the bootstrap method is invoked, it needs to create a

 * {@link java.lang.invoke.CallSite} object. In Dynalink, these call sites need

 * to additionally implement the {@link jdk.dynalink.RelinkableCallSite}

 * interface. "Relinkable" here alludes to the fact that if the call site

 * encounters objects of different types at run time, its target will be changed

 * to a method handle that can perform the operation on the newly encountered

 * type. {@link jdk.dynalink.support.SimpleRelinkableCallSite} and

 * {@link jdk.dynalink.support.ChainedCallSite} (not used in the above example)

 * are two implementations already provided by the library.</li>

 * <li>Dynalink uses {@link jdk.dynalink.CallSiteDescriptor} objects to

 * preserve the parameters to the bootstrap method: the lookup and the method type,

 * as it will need them whenever it needs to relink a call site.</li>

 * <li>Dynalink uses {@link jdk.dynalink.Operation} objects to express

 * dynamic operations. It does not prescribe how would you encode the operations

 * in your call site, though. That is why in the above example the

 * {@code parseOperation} function is left empty, and you would be expected to

 * provide the code to parse the string {@code "GET:PROPERTY:color"}

 * in the call site's name into a named property getter operation object as

 * {@code StandardOperation.GET.withNamespace(StandardNamespace.PROPERTY).named("color")}.

 * </ul>

 * <p>What can you already do with the above setup? {@code DynamicLinkerFactory}

 * by default creates a {@code DynamicLinker} that can link Java objects with the

 * usual Java semantics. If you have these three simple classes:

 * <pre>

 * public class A {

 *     public String color;

 *     public A(String color) { this.color = color; }

 * }

 *

 * public class B {

 *     private String color;

 *     public B(String color) { this.color = color; }

 *     public String getColor() { return color; }

 * }

 *

 * public class C {

 *     private int color;

 *     public C(int color) { this.color = color; }

 *     public int getColor() { return color; }

 * }

 * </pre>

 * and you somehow create their instances and pass them to your call site in your

 * programming language:

 * <pre>

 * for each(var obj in [new A("red"), new B("green"), new C(0x0000ff)]) {

 *     print(obj.color);

 * }

 * </pre>

 * then on first invocation, Dynalink will link the {@code .color} getter

 * operation to a field getter for {@code A.color}, on second invocation it will

 * relink it to {@code B.getColor()} returning a {@code String}, and finally on

 * third invocation it will relink it to {@code C.getColor()} returning an {@code int}.

 * The {@code SimpleRelinkableCallSite} we used above only remembers the linkage

 * for the last encountered type (it implements what is known as a <i>monomorphic

 * inline cache</i>). Another already provided implementation,

 * {@link jdk.dynalink.support.ChainedCallSite} will remember linkages for

 * several different types (it is a <i>polymorphic inline cache</i>) and is

 * probably a better choice in serious applications.

 * <h2>Dynalink and bytecode creation</h2>

 * {@code CallSite} objects are usually created as part of bootstrapping

 * {@code invokedynamic} instructions in bytecode. Hence, Dynalink is typically

 * used as part of language runtimes that compile programs into Java

 * {@code .class} bytecode format. Dynalink does not address the aspects of

 * either creating bytecode classes or loading them into the JVM. That said,

 * Dynalink can also be used without bytecode compilation (e.g. in language

 * interpreters) by creating {@code CallSite} objects explicitly and associating

 * them with representations of dynamic operations in the interpreted program

 * (e.g. a typical representation would be some node objects in a syntax tree).

 * <h2>Available operations</h2>

 * Dynalink defines several standard operations in its

 * {@link jdk.dynalink.StandardOperation} class. The linker for Java

 * objects can link all of these operations, and you are encouraged to at

 * minimum support and use these operations in your language too. The

 * standard operations {@code GET} and {@code SET} need to be combined with

 * at least one {@link jdk.dynalink.Namespace} to be useful, e.g. to express a

 * property getter, you'd use {@code StandardOperation.GET.withNamespace(StandardNamespace.PROPERTY)}.

 * Dynalink defines three standard namespaces in the {@link jdk.dynalink.StandardNamespace} class.

 * To associate a fixed name with an operation, you can use

 * {@link jdk.dynalink.NamedOperation} as in the previous example:

 * {@code StandardOperation.GET.withNamespace(StandardNamespace.PROPERTY).named("color")}

 * expresses a getter for the property named "color".

 * <h2>Operations on multiple namespaces</h2>

 * Some languages might not have separate namespaces on objects for

 * properties, elements, and methods, and a source language construct might

 * address several of them at once. Dynalink supports specifying multiple

 * {@link jdk.dynalink.Namespace} objects with {@link jdk.dynalink.NamespaceOperation}.

 * <h2>Language-specific linkers</h2>

 * Languages that define their own object model different than the JVM

 * class-based model and/or use their own type conversions will need to create

 * their own language-specific linkers. See the {@link jdk.dynalink.linker}

 * package and specifically the {@link jdk.dynalink.linker.GuardingDynamicLinker}

 * interface to get started.

 * <h2>Dynalink and Java objects</h2>

 * The {@code DynamicLinker} objects created by {@code DynamicLinkerFactory} by

 * default contain an internal instance of

 * {@code BeansLinker}, which is a language-specific linker

 * that implements the usual Java semantics for all of the above operations and

 * can link any Java object that no other language-specific linker has managed

 * to link. This way, all language runtimes have built-in interoperability with

 * ordinary Java objects. See {@link jdk.dynalink.beans.BeansLinker} for details

 * on how it links the various operations.

 * <h2>Cross-language interoperability</h2>

 * A {@code DynamicLinkerFactory} can be configured with a

 * {@link jdk.dynalink.DynamicLinkerFactory#setClassLoader(ClassLoader) class

 * loader}. It will try to instantiate all

 * {@link jdk.dynalink.linker.GuardingDynamicLinkerExporter} classes visible to

 * that class loader and compose the linkers they provide into the

 * {@code DynamicLinker} it creates. This allows for interoperability between

 * languages: if you have two language runtimes A and B deployed in your JVM and

 * they export their linkers through the above mechanism, language runtime A

 * will have a language-specific linker instance from B and vice versa inside

 * their {@code DynamicLinker} objects. This means that if an object from

 * language runtime B gets passed to code from language runtime A, the linker

 * from B will get a chance to link the call site in A when it encounters the

 * object from B.