What's new in 0.5

Changes in 0.5 compared to 0.4

RelinkableCallSite.setRelinkAndInvoke() is now named RelinkableCallSite.initialize().
RelinkableCallSite.setGuardedInvocation() is now named RelinkableCallSite.relink().
RelinkableCallSite now has a new method that must be implemented, resetAndRelink().
Lots of methods for adaptation of CallSiteDescriptor have been moved out of the interface, lessening the implementation burden for it. Only a generic adapter changeMethodType(MethodType) remains, and others are now reimplemented in terms of it as static methods on CallSiteDescriptorFactory.

Detection of frequently relinked call sites. DynamicLinkerFactory.setUnstableRelinkThreshold() can be used to set the number of times a call site has to be relinked to be considered unstable. Once such a call site was detected, subsequent requests to link it will return true from the new method LinkRequest.isCallSiteUnstable(). Individual linkers can use this flag as a hint that they should try to produce linkage that is more stable (and probably more generic and thus less efficient, but still more efficient than the call site constantly being relinked).
StaticClassLinker now exposes static inner classes as properties of the outer class.
Dynalink is even more security-savvy than before; even if it itself runs with wide set of privileges in a JVM with a security manager present, it will not allow access to classes in restricted packages (those normally specified in package.access property of the jre/lib/security/java.security file).

DynamicLinker.getRelinkedCallSiteLocation() provides access to the location (class name, file, line number) of the call site being relinked on the current thread.
GuardedInvocation.asType(LinkerServices, MethodType) for convenient coercing of invocation and guard using all language-specific conversions.

There is now more information in Dynalink's JAR file manifest, and a JAR index is also produced.
Fixed a bug with exposing boolean static properties defined with an isXxx() static getter method.
Fixed a bug that failed to convert the guard when the invocation was already of correct method type in GuardedInvocation.asType(MethodType).