Weld 3.1.7.Final

2021-3-18 release Matej Novotny

Weld 3.1.7.Final along with API 3.1.SP4 is now up for grabs!

Along a few bugfixes, the flagship of this release is a rework of Weld’s default class defining utilities which should eliminate those pesky JDK 11+ warnings about illegal reflective access. You can find more details on it below or in the JIRA ticket; in case you encounter any issue with it, please don’t hesitate to reach out to us.

So, let’s take a closer look:

Class Defining in Weld
- Weld Core is now a Multi-Release JAR providing two different implementations for JDK 8 and JDK 11 or newer
- Integrators are still encouraged to implement ProxyServices class from our API
  - All implementations of this interface are now presumed to support class defining (ProxyServices#supportsClassDefining() is now deprecated and not used)
- For SE environment or an integrator that doesn’t implement the aforementioned API, Weld now provides a default implementation of ProxyServices which:
  - On JDK 8 behaves the same as it did until now - it cracks open ClassLoader.defineClass(…) method and uses that
  - On JDK 11+ it uses a combination of MethodHandles.Lookup and a custom ClassLoader; the former is used for vast majority of cases with class loader being a solution for edge cases such as default packages or beans from signed JARs
Other Weld Core Fixes
- BeanAttributesConfigurator could incorrectly initialize default qualifiers when @Named was involved (WELD-2659)
- Synthetic alternative beans did not trigger ProcessBean event as they should when enabled (WELD-2658)
- Fixed proxy creation for beans in default package (WELD-2657)
- Fixed a corner case scenario where a hierarchy of classes with bridge methods would not get correctly intercepted (WELD-2656)

WildFly Patch

There is no WildFly patch at the moment. We are currently exploring how to properly ship a patch that would align with WildFly usage of Galleon; the tracking JIRA can be seen (here).

[ Download ] [ Documentation ] [ Release notes ]