I originally logged this against Spring Boot (https://github.com/spring-projects/spring-boot/issues/24686), but it seems that https://github.com/spring-projects/spring-framework/pull/25852 breaks deployment of a war file built against Spring Framework 5.3 (from Spring Boot 2.4) to Wildfly 9 running on JDK 8. (We're currently unable to upgrade to a newer version of Wildfly.)
Comment From: jhoeller
I'm afraid there is not much we can do about this. With Spring Framework 5.3.x set up as a long-term support branch, we need to focus on a fine default experience on 2020/2021-era infrastructure, including recent versions of WildFly.
For the time being, I'm afraid you'll either have to stay on Spring Framework 5.2.x (Boot 2.3.x) or patch the manifest of our spring-core.jar. I'll repurpose this ticket for upgrade notes on the WildFly 9 incompatibility, making this more obvious.
Comment From: jhoeller
I've added a corresponding note to https://github.com/spring-projects/spring-framework/wiki/Upgrading-to-Spring-Framework-5.x
Comment From: rajbdilip
Hi, @jhoeller.
Please correct if my understanding is wrong but I believe Spring 5.3+ supports Java 8? And jdk.unsupported module is introduced as a part of Java 9. So, it's kinda like we are supporting JDK 8 but we are also mandating the presence of a module that JDK 9 introduced.
My organization has several products based on Spring and are being deployed on hundreds of servers. There are migration plans to the recent Containers which provides jdk.unsupported module but it will take a considerable time given the number of servers and process involved. But we are having to upgrade to latest version of Boot (2.5) for OSS issues resolution. So, it's kind of like a deadlock situation.
Manually patching the JAR isn't something that is doable for us. Having an option (which doesn't involve hacking Spring core) would be really great.
Comment From: jhoeller
This is a very much a WildFly problem where a WildFly-specific deployment hint is necessary for the jdk.unsupported module to be visible on JDK 9+; the same code is implicitly present on JDK 8 as well. Spring Framework 5.3 as well as the latest versions of WildFly still support Java 8, just with a focus on Java 9+ these days (including some runtime optimizations and deployment hints). Unfortunately that JDK 8/9 bridging support was still rather early on WildFly 9; later versions of WildFly fine-tuned it.
So to be clear, there is no need to upgrade to JDK 9+ for a resolution here, just to a more recent version of WildFly that ignores the deployment hint if jdk.unsupported is not present at runtime. Our recommendation is to stay on JDK 8 and unchanged Spring Framework 5.3.x jars for the time being, just upgrading your WildFly version. (Please note that WildFly 9 is long out of date and not supported by Red Hat anymore either as far as we aware, not even for security vulnerabilities etc.)
Comment From: rajbdilip
I'm sorry I should have mentioned this ahead. We are actually using JBoss EAP 7.1 which is based on WildFly but not bundled with Wildly (as this thread suggests). The thread also suggests that while EAP and WildFly codebases are NOT identical and cannot be mapped, EAP 7.1 is based on Wildfly 11. What do you think it means for JDK 8/9 Bridging support you mentioned?
And as far as EAP goes, 7.x is the latest series (with 7.3 being the latest) and has many more support years left.
Deployment does work with 7.3 but migration to 7.3 in hundred of servers is a very time taking process (ignoring the effort involved) (given the number of servers, process and some breaking changes in 7.3 in other dependencies involved) but OSS support is already over for Boot 2.3.x.
Comment From: jhoeller
I'm not sure when exactly WildFly revised their deployment hint processing to leniently ignore non-present modules on JDK 8. It's definitely the case with all WildFly versions that we tested in 2020 and 2021. That's what we need to optimize for on our end: a smooth out-of-the-box experience with recent WildFly/JBoss versions on JDK 9+ (which requires that deployment hint).
Please note that JBoss EAP 7.1 won't get further patch releases anymore, with Red Hat themselves suggesting an upgrade to EAP 7.2/7.3: https://access.redhat.com/solutions/3824062 - Like with Spring Boot, their expectation is that you keep upgrading to recent minor versions within the JBoss EAP 7 generation under Red Hat's commercial support.
Also, while active development on Spring Boot 2.3.x ended in the meantime, it's not EOL yet (as the support page states). If you need to stay on JBoss EAP 7.1.x (with its last ever release in early 2019), you may simply stay on Spring Boot 2.3.12 (released in June 2021). You're still clearly out of date on your JBoss version, not on your Boot version, then.
Alternatively, and highly recommended, our advice is to follow Red Hat's advice: prioritize your JBoss EAP upgrade and upgrade to Spring Boot 2.4/2.5 along with it. Since even JBoss EAP 7.2 won't get further patch releases anymore as far as I can see, a straight upgrade to JBoss EAP 7.3 seems necessary: https://access.redhat.com/articles/2332721
Last but not least, there's not just the workaround with removing the manifest entry from the spring-core-5.3.x jar, there's also a workaround to create a dummy jdk.unsupported module in your WildFly setup: https://stackoverflow.com/questions/65100927/springboot-wildfly-10-deployment-error-jdk-unsupported-module-not-found/68318243#68318243
Hope that helps so far. I'm afraid there is no more we can do about this.