IBM Developer Blog

Follow the latest happenings with IBM Developer and stay in the know.

The Open Liberty team is committed to supporting developers by making Jakarta EE 9 the best framework for open source cloud-native Java that it can…


With the release of Jakarta EE 8, enterprise Java technology joined the open source community. Despite the massive scale of this undertaking, which involved scores of projects, tests, meetings, presentations, and deliberations, the transition was a huge success, providing Java developers worldwide with an open source platform for cloud-native enterprise applications.

However, the next challenge for Jakarta EE was already on deck. Although Jakarta EE 8 was fully compatible with its Java EE 8 predecessor, for the Jakarta EE 9 release, all the specification package prefixes had to be changed from javax to jakarta. For a cloud-native Java runtime, such as Open Liberty, the challenge is to ensure that this change results in as little disruption as possible for application developers.

Open Liberty team contributions to Jakarta EE

Luckily, the Open Liberty development team is no stranger to Jakarta EE. The team’s involvement with Jakarta EE goes back the beginning of the project. We believe in the importance of an open source, vendor-neutral framework for cloud-native enterprise Java applications. Our team is active across the Jakarta Working Group, with Kevin Sutter serving as a co-release lead, Dan Bandera and Ian Robinson sitting on the Steering Committee, and Alasdair Nottingham directing the implementation on Open Liberty.

Open Liberty was certified as Jakarta EE 8 compatible as of our 19.0.0.6 release in June of 2019. Since then, we have been working to prepare the runtime for Jakarta EE 9 compatibility.

Our developers are committers to numerous Jakarata EE specifications, including Connectors, Concurrency, and XML Web Services. We are taking a leading role in the Jakarta EE Platform umbrella specification. We are also providing leadership and support for the Eclipse Transformer project, which is an important resource for making the transition to Jakarta EE 9. This project supports changing package names from javax to jakarta by enabling a class loader to dynamically rename type references at runtime while classes are being loaded. We have been using this tool on Open Liberty to bytecode-rewrite Jakarta EE 8 references to Jakarta EE 9.

For Jakarta EE 9, Open Liberty is ready when you are

The Open Liberty zero migration architecture ensures that existing, unmodified configuration and application files work with an updated version of Open Liberty, without unexpected changes in application behavior. To preserve this principle, the changes to Jakarta package names are delivered in new feature versions, as are all significant changes to Open Liberty. Therefore, Jakarta EE 8 applications can continue to use the old package names with older feature versions, while Jakarta EE 9 applications can use newer feature versions with the new package names. The Open Liberty beta releases are now fully Jakarta EE 9 compatible. And while we are working to make the main Open Liberty release Jakarta EE 9 compatible as soon as possible, our users have the flexibility to make the change whenever they see fit.

Test drive Jakarta EE 9 with Open Liberty betas

Since June of 2020, we have gradually introduced new Jakarta EE 9-ready features in our four-week beta releases. So far, we’ve added features that provide access to a wide range of Jakarta APIs, including JDBC, Persistence, Concurrency, WebSockets, JSON P, JSON B, and many more. You can try out the Jakarta EE 9 features that we have so far by building either our All Beta Features package or our Jakarta EE 9 Beta Features package.

The following Jakarta EE 9-ready Open Liberty features are available now through our beta packages:

  • JakartaMail (mail-2.0)
  • Jakarta Faces Container 3.0 (facesContainer-3.0)
  • Jakarta Enterprise Beans Persistent Timer 4.0 (enterpriseBeansPersistentTimer-4.0)
  • Jakarta WebSocket 2.0 (websocket-2.0; now with full CDI integration)
  • RESTful Web Services 3.0 (restfulWS-3.0 and restfulWSClient-3.0)
  • Jakarta Server Faces 3.0 (faces-3.0)
  • Jakarta Connectors 2.0 (connectors-2.0)
  • Jakarta Enterprise Beans 4.0 (enterpriseBeans-4.0)
  • Jakarta Enterprise Beans Remote 4.0 (enterpriseBeansRemote-4.0)
  • Jakarta Enterprise Beans Home 4.0 (enterpriseBeansHome-4.0)
  • Jakarta Enterprise Beans Lite 4.0 (enterpriseBeansLite-4.0)
  • Jakarta EE Application Client 9.0 (javaeeClient-9.0)
  • Jakarta Authentication 2.0 (jaspic-2.0)
  • Jakarta Authorization 2.0 (jacc-2.0)
  • Jakarta Persistence 3.0 (includes Eclipselink 3.0-RC1.) (jpa-3.0)
  • Jakarta XML Binding 3.0 (jaxb-3.0)
  • Jakarta Managed Beans 2.0 (managedBeans-2.0)
  • Jakarta Concurrency 2.0 (concurrent-2.0)
  • Jakarta Bean Validation 3.0 (beanValidation-3.0)
  • Jakarta Contexts and Dependency Injection 3.0 (cdi-3.0)
  • Message-Driven Beans 4.0 (mdb-4.0)
  • JDBC 4.2 & 4.3 (jdbc-4.2 & jdbc-4.3)
  • Jakarta Transactions 2.0 (transaction-2.0)-
  • Jakarta JSON Binding 2.0 (jsonb-2.0)
  • Jakarta JSON Processing 2.0 (jsonp-2.0)
  • Jakarta Servlet 5.0 (servlet-5.0)
  • Jakarta Server Pages 3.0 (pages-3.0)
  • Jakarta Expression Language 4.0 (expressionLanguage-4.0)
  • Jakarta Messaging 3.0 (messaging-3.0, messagingClient-3.0, messagingServer-3.0, messagingSecurity-3.0)
  • Jakarta Security 2.0 (appSecurity-4.0, appSecurityClient-1.0)
  • Jakarta Batch 2.0 (batch-2.0)
  • Jakarta XML Web Services 3.0 (xmlWS-3.0)

We continue to add more Jakarta EE 9 features every four weeks in our beta releases as we work toward full compatibility. The Open Liberty team is committed to supporting developers by making Jakarta EE 9 the best framework for open source cloud-native Java that it can be. You can follow our progress on the Open Liberty blog. To learn more about Open Liberty, see our Open Liberty guides on Jakarta EE technologies. You can also let us know what you think on our mailing list, we’d love to hear from you!