markkwsu
WebSphere and JBoss are considered the two major commercial software options in the JavaEE middleware market. After the traditional WebSphere Application Server ceased updating its JDK (remaining on IBM JDK 8), users looking to transition to the next generation of specifications must choose between WebSphere Liberty and JBoss EAP. In this article, I will explore the reasons behind my choice of WebSphere Liberty by examining two key aspects: JVM support and Java EE/Jakarta EE specification support.
I will start with the JVM aspect. JBoss EAP 7.4 officially claims to support the following JVMs:
https://access.redhat.com/articles/2026253
It is evident that Red Hat deliberately supports only OpenJDK and Oracle JDK. In an enterprise environment, it is common to require both middleware and JVM to have commercial support. After all, when issues arise, the problem may not solely lie with the middleware but could also stem from the JVM. Whether using an open-source solution or middleware and JVM from different vendors, these scenarios can potentially increase the complexity of troubleshooting.
What piques my curiosity is that JBoss EAP does not support Eclipse Temurin, even though Red Hat is actively involved in this project and provides commercial support for it. It’s unclear why Temurin is not included in the list of supported JVMs. Instead, Eclipse OpenJ9 is listed as a supported JVM—an interesting choice, especially considering that it even includes a specific version: 11.
Let’s take a look at the open-source version of JBoss EAP, WildFly:
https://docs.wildfly.org/30/Getting_Started_Guide.html#requirements
WildFly is relatively less restrictive. The latest version, 30 Final, only requires Java SE 11 or higher, while 22 Final supports Java SE 8 or higher, depending on the JavaEE/JakartaEE versions supported by these releases. This flexibility allows users to choose their preferred JVM freely.
Next, let’s look at WebSphere Liberty. Officially, it claims to support the following JVMs (use https://www.ibm.com/software/reports/compatibility/clarity/softwareReqsForProduct.html to get this result):
As shown above, WebSphere Liberty supports all JVMs that comply with Java SE 8, 11, 17, or 21 specifications. This means you can choose OpenJDK, Oracle JDK, IBM JDK, or any other compatible JDK.
As for the open-source version of WebSphere Liberty, Open Liberty, it supports the following JVMs:
https://openliberty.io/docs/latest/java-se.html
This feels more deliberate. Open Liberty officially claims to support only IBM’s own (or closely controlled) JVMs. However, it is worth noting that it does support Java SE 23, which is a plus.
Next, let’s look at the specification support:
The latest Jakarta EE 10 was released on 2022/09/22. Since WebSphere Liberty aligns its versions with Open Liberty, it has supported Jakarta EE 10 starting from 23.0.0.3 (March 2023 release). JBoss EAP 8.0, however, was not released until February 2024, making it the first JBoss version to support Jakarta EE 10.
After reviewing support for the new specifications, let’s now examine the backward compatibility capabilities.
WebSphere Liberty/Open Liberty is developed using an OSGi architecture, allowing features to determine which specifications the server can support. Based on my personal experience, I prefer using Liberty’s kernel version (approximately 14MB) to build the foundation of the entire runtime environment.
Therefore, WebSphere Liberty/Open Liberty can support a wide range of specifications, from Jakarta EE 10 all the way down to Jakarta EE 9.1, Java EE 8, Java EE 7, and even Java EE 6 (Update: Strictly speaking, it’s not full Java EE 6, but rather Java EE Web Profile 6, and this support is only available in WebSphere Liberty, not Open Liberty). This provides an excellent migration path for users of the traditional WebSphere Application Server.
This is something that JBoss EAP 8.0 cannot achieve. If JBoss EAP needs to ensure backward compatibility with specifications below Java EE 8, it must downgrade to JBoss EAP 7.4. As a result, it becomes impossible to use the same install base to accommodate the specification requirements of various applications.
However, the feature-based approach of WebSphere Liberty/Open Liberty is not without its drawbacks. The main issue arises when you choose not to use a complete Java EE or Jakarta EE feature set but instead opt for specific specifications like Servlet or JSP. In such cases, you may encounter dependency issues between the versions of these individual specifications. At this point, you’ll need an experienced expert (like me, for example) to assist with evaluation and even application adjustments. 😛
From an ecosystem perspective, WebSphere Liberty/Open Liberty is not entirely without flaws. However, the issues observed so far can generally be resolved with the help of experienced experts like me, you can contact me using: i@marksu.idv.tw.
Add comment