Choosing the Right JDK for WildFly and JBoss EAP

This tutorial discusses the recommended JDK versions for WildFly and JBoss Enterprise Application Platform (EAP), as well as how to configure the Java runtime for your deployments. The article is updated to August 2026 and reflects the latest server generations, including WildFly 40/41 and JBoss EAP 8.x.

WildFly and JBoss EAP JDK Compatibility at a Glance

Navigating Java and Jakarta EE compatibility across WildFly and JBoss EAP can be challenging due to rapid release cycles. Here is what you need to know at a glance:

• WildFly 28–34: Minimum Java 11, recommended Java 17/21 (Jakarta EE 10 baseline). WildFly 34 is the final series supporting Java 11.
• WildFly 35–39: Minimum Java 17, recommended Java 21 (LTS). Support for Java 11 is completely dropped.
• WildFly 40–41: Minimum Java 17, introducing Jakarta EE 11 in the standard release (Java 25 recommended) while maintaining a companion Jakarta EE 10 variant (Java 21 recommended).
• JBoss EAP 8.0: Requires Java 11 or 17 (Java 17 recommended; JDK 8 dropped). Supports Jakarta EE 10.
• JBoss EAP 8.1: Requires Java 17, with full support for Java 21 (LTS recommended; Java 11 dropped). Supports Jakarta EE 10.

Choosing the right JDK for your WildFly or JBoss EAP deployment isn’t just a matter of basic compatibility—it is a core architectural decision that directly impacts performance, garbage collection efficiency, security, and enterprise support lifecycles. With multiple JDK vendors and rapid Java release cycles, aligning your runtime with official Technology Compatibility Kit (TCK) certifications is essential for maintaining a stable production environment.

Currently, the minimum Java version required for modern WildFly releases (WildFly 35 and newer) is Java 17 (Oracle JDK or OpenJDK).

JDK Compatibility for Each WildFly Version

Each WildFly release defines a minimum JDK requirement and a maximum tested JDK version. You should select a JDK within the supported Min-Max range outlined below:

Recommended JDK Versions for WildFly

• WildFly up to 26: Runs on Java 8 or Java 11. Due to extensive test coverage, JDK 11 is the recommended LTS choice for legacy installations.
• WildFly 27 to 34: Drops support for Java 8, establishing Java 11 as the minimum baseline. While Java 11 is supported through WildFly 34, upgrading to Java 17 or Java 21 is strongly recommended. Note that WildFly 34 is the final release series supporting Java 11.
• WildFly 35 to 39: Completely removes support for Java 11. The minimum runtime requirement is Java 17, while Java 21 (LTS) is the primary recommended JDK for production workloads.
• WildFly 40 and 41: Introduces Jakarta EE 11 support for the standard distribution. For standard EE11 builds, Java 25 (LTS) is recommended, while Java 21 remains recommended for the companion WildFly EE10 variant. Note: SecurityManager cannot be enabled when running Jakarta EE 11 builds.

Official Java and Jakarta EE certification matrices can be verified in the WildFly Certifications Repository.

JBoss Enterprise Application Platform (EAP 7 and EAP 8)

To run in a fully supported Red Hat enterprise configuration, JBoss EAP must execute on a Technology Compatibility Kit (TCK) certified JDK implementation on a supported operating system. Below is the supported JDK matrix across JBoss EAP major releases:

For detailed support lifecycle matrices, refer to the official Red Hat JBoss EAP Supported Configurations KCS Article.

How to Set the Java Version in JBoss EAP or WildFly

Configuring the JDK executable and JVM settings for Standalone mode is done via startup configuration scripts located in the bin folder:

• Linux/Unix: bin/standalone.conf
• Windows: bin/standalone.conf.bat

To explicitly define which Java installation WildFly or JBoss EAP should use, set the JAVA_HOME variable inside standalone.conf:

# Specify the explicit path to your target JDK installation
JAVA_HOME="/usr/lib/jvm/java-21-openjdk"

# Customize JVM memory flags and Metaspace parameters
JAVA_OPTS="-Xms512m -Xmx2048m -XX:MaxMetaspaceSize=512m -Djava.net.preferIPv4Stack=true"

For Domain mode configurations spanning multiple host controllers, refer to our detailed guide on How to Configure WildFly in Domain Mode.

Practical Recommendations for Upgrades and Migrations

Upgrading your application server or underlying JDK requires a structured strategy to ensure stability, maintain security compliance, and optimize performance. Consider the following recommendations for your upgrade path:

• Standardize on LTS JDK Releases: Always target the latest Long-Term Support (LTS) JDK supported by your server generation (e.g., Java 17 for WF 28–31/EAP 8.0; Java 21 for WF 32–39/EAP 8.1; Java 25 for WF 40+). LTS releases benefit from extended security patching and garbage collection optimizations.
• Execute Comprehensive Integration Testing: Validate application compatibility using integration test suites and TCK profiles. Leverage automation utilities such as the Red Hat Migration Toolkit for Applications (MTA), the Server Migration Tool (for EAP 7 to EAP 8 upgrades), or WildFly Prospero to streamline server configuration updates.
• Adopt Staged Rollouts and Backups: Deploy upgrades incrementally across Staging/QA environments before pushing to Production. Always maintain snapshot backups of server configuration files (standalone.xml, domain.xml) and database state to support rapid rollback if unexpected runtime issues arise.
• Understand Runtime Compatibility: WildFly and JBoss EAP execute as standard JVM classpath applications on certified distributions (Red Hat OpenJDK, Oracle JDK, Eclipse Adoptium, Azul Zulu). Note that GraalVM native-image is not a standard runtime target for traditional WildFly or JBoss EAP application deployments.
• Monitor JVM Performance Metrics Post-Migration: Following a Java runtime upgrade, closely monitor memory utilization, garbage collection pause times, and thread states to fine-tune your JAVA_OPTS parameters for production workloads.

Disclaimer

This website is independently operated and is not affiliated with or maintained by Red Hat. The views expressed here are solely those of the author at the time of writing. It is strongly recommended to consult Red Hat’s official website or seek professional guidance from Red Hat or certified professionals before implementing JBoss EAP in production systems. The author does not assume responsibility for decisions or actions taken based on the information provided on this website.