What's new in 0.7

Changes in 0.7 compared to 0.6

Summary

This release mainly focuses on enhancements in interaction with Java security subsystems as well as a discovery mechanism for dynamic property and method names on beans, in addition to a number of bug fixes.

Minor new features

• BeansLinker now exposes methods to retrieve all known names of dynamically accessible properties and methods: getReadableInstancePropertyNames(Class), getWritableInstancePropertyNames(Class), getInstanceMethodNames(Class), getStaticReadablePropertyNames(Class), getStaticWritablePropertyNames(Class), and getStaticMethodNames(Class).

Improvements and fixes

• Caller-sensitive JDK methods (those with @sun.reflect.CallerSensitive annotation) introduced in Oracle Java 7u25 are correctly handled by Dynalink.
• Fixed a bug in matching explicit method types to overloads.
• Fixed a bug in reporting the call site location in DynamicLinker.getRelinkedCallSiteLocation().
• DynamicLinker.getRelinkedCallSiteLocation() was renamed to DynamicLinker.getLinkedCallSiteLocation() to reflect that it can be used on first link event too. The old method name is kept around as deprecated for a while.
• Thrown away code for zero-privilege lookup delegate; we're using public lookup again. While this eliminates some unnecessary complexity, it can cause issues when Dynalink is used with a SecurityManager on Java older than 7u25. It is therefore strongly recommended to only use Dynalink 0.7 with Java 7u25 or newer when run in an environment with a SecurityManager.
• Judicious use of doPrivileged to retrieve class loaders when they're used internally.

Backwards incompatible changes

• Removed support for JSR-292 Java 6 backport to reduce maintenance effort. Dynalink is now Java 7+ only.
• Access to constructors of classes in restricted packages when running under a SecurityManager is no longer allowed. This is consistent with preventing access to their methods.
• DynamicLinkerFactory now defers retrieval of thread context class loader until absolutely necessary, instead of proactively retrieving it. This can change the behavior as the thread context class loader is not retrieved at the construction time of factory, but rather when its createLinker method is invoked. In practice, this rarely if ever means a difference as the construction of the factory and invocation of its linker creation method are practically always executed on the same thread one after the other. Retrieval of the thread context class loader is a security-checked operation, so we try to avoid it if we don't need it.