Skip to content
Attila Szegedi edited this page Aug 8, 2013 · 5 revisions

Changes in 0.7 compared to 0.6

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 JDK 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.
  • 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.
Clone this wiki locally