Repository navigation
META-INF/MANIFEST.MF must include Dependencies: jdk.unsupported for Wildfly deployment #3303
Description
Hello,
ehCache uses sun.misc.Unsafe in ehcache-impl which is provided by jdk.unsupported module.
WildFly builds >=29 became quite strict in providing access to jdk.unsupported by default.
We currently use a manually patched ehcache.jar with "Dependencies: jdk.unsupported" added into the ehcache MANIFEST.MF to successfully deploy on wildfly.
To avoid having patch every new release it would be nice if the dependency declaration would be available directly. Unless you plan to move away from Unsafe-usage shortly.. ;)
The same issue was handled by Classgraph [1] with suggestions from Wildfly-Devs [2]. Related Documentation is available at [3, 4]
Best regards,
Samuel
[1] classgraph/classgraph#808
[2] https://groups.google.com/g/wildfly/c/V8zQOFwpym0
[3] https://docs.wildfly.org/30/Developer_Guide.html#JAX_WS_JBoss_Modules_and_WS_applications
[4] https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_application_platform/7.4/html/development_guide/class_loading_and_modules#add_an_explicit_module_dependency_to_a_deployment
Activity
Fixes ehcache#3303 : declare module dependencies for clean wildfly
SamuelBussmann commentedon Dec 6, 2025
#3257 might be related to this as well
Shaquarib commentedon Aug 12, 2026
This is a request to add an explicit JPMS/module dependency to Ehcache's manifest so deployments on newer WildFly versions can access jdk.unsupported. The proposed change is reasonable: declaring the dependency directly would eliminate the need for downstream users to patch each release.
If you're evaluating this as an issue/PR, the key technical point is that sun.misc.Unsafe is exposed through the jdk.unsupported module, and WildFly's module/classloading behavior means the application should explicitly declare that dependency rather than relying on it being implicitly available.
A concise response could acknowledge the issue and indicate that the manifest will be updated.