As many enterprise applications have been built using Java EE, migrating these applications to JakartaEE 10 is a key concern for developers. JakartaEE 10 is the latest version of the enterprise Java standard, and it provides a platform for building portable, cloud-native applications.
In this talk, we will explore the challenges and opportunities of migrating from Java EE to JakartaEE 10. We will begin by discussing the differences between Java EE and JakartaEE, and how the migration process differs from previous upgrades. We will then explore the steps involved in migrating an application, such as identifying the modules that need to be updated, testing the application, and deploying it to a JakartaEE 10 runtime.
One of the key challenges in migrating from Java EE to JakartaEE 10 is dealing with the removal of some of the legacy technologies that were present in earlier versions of Java EE. We will discuss strategies for dealing with this, such as using alternative technologies or refactoring the code to remove dependencies on these legacy technologies.
Throughout the talk, we will provide practical tips and best practices for migrating from Java EE to JakartaEE 10, based on our own experiences and those of the broader community. By the end of the talk, developers will have a better understanding of the challenges and opportunities of migrating to JakartaEE 10, and will be equipped with the knowledge and tools they need to make a successful transition.
5. Reason for app
migration
▸ Outdated technology (e.g., technology E.O.L.)
▸ Security Enhancements (remember Zero Day
exploit?)
▸ Cost efficiency
▸ Vendor Lock-in
▸ Integration needs
▸ Long-term sustainability
And many more.
6
6. Migration approach
▸ Reactively
▹ You don’t know what you don’t know until it
happens.
▸ Proactively
▹ You know of the impact that will affect your
application, so you address it before it
becomes problematic.
7
7. Migration strategies
(the 6 R’s)
For your organisation’s applications, some
commonly known ones:
▸ Rehost (hosting your on-premise application to
the cloud)
▸ Replatform (modernising your existing
application to newer technology
stacks/environments, without changing its
existing architecture)
8
8. Migration strategies
For your organisation’s applications, some
commonly known ones:
▸ Repurchasing (replacing your application with a
solution that provides the same or similar
capabilities)
▸ Refactoring/Re-architect: Re-architect and
develop the application to be optimised to run
to new environment
9
9. Migration Strategies
▸ Retire/Decommission: Old application are
retired, and newer versions are written to
replace the old application.
▸ Retain (do nothing and revisit later). Keeping
the application AS-IS because there is no need
for migration.
10
11. Jakarta EE versions
12
Platform version Released Date Specification Java SE support
Jakarta EE 10 13 September 2022 10 Java SE 17 / 11
Jakarta EE 9.1 25 May 2021 9.1 Java SE 11 / 8
Jakarta EE 9 08 December 2020 9 Java SE 8
Jakarta EE 8 10 September 2019 8 Java SE 8
Java EE 8 31 August 2017 JSR 366 Java SE 8
Java EE 7 28 May 2013 JSR 342 Java SE 7
Java EE 6 10 December 2009 JSR 316 Java SE 6
Java EE 5 11 May 2006 JSR 244 Java SE 5
J2EE 1.4 11 November 2003 JSR 151 J2SE 1.4
J2EE 1.3 24 September 2001 JSR 58 J2SE 1.3
J2EE 1.2 17 December 1997 1.2 J2SE 1.2
12. Jakarta EE today…
▸ Visible release cycle
▹ Since 2019 to 2022
– 3 major Jakarta
EE releases
▸ Quick adoption for
standardisation of
latest industry
technologies
▹ Cloud adoption
(Microprofile)
▹ NoSQL standards
for Java (jNoSQL)
▸ Quick adoption to latest
(active) Java version
▹ Possible adoption
of Java records
(Java 17)
▹ Adoption of virtual
threads (Java 21)
13
13. What about Jakarta
EE 11?
▸ Java 21 General Availability release date: 19
September 2023
▸ Jakarta EE 11 target release date: first quarter
of 2024 (allowing enough time to build and test
projects to take advantage of Java 21
capabilities).
14
15. Spring Frameworks with
Jakarta EE
16
Release version Released Date Jakarta EE version Java SE support
6.1.x 15 November 2023 10 Java SE 17 / 11
6.0.x 16 November 2022 9 Java SE 17 - 21
5.3.x 27 October 2020 Java EE 8 Java SE 8 / 11 / 17
5.2.x 30 September 2019 Java EE 8 Java SE 8
5.1.x 20 September 2018 Java EE 7 / 8 Java SE 8
16. Jakarta EE
technologies in Spring
▸ Servlet API (JSR 340)
▸ WebSocket API (JSR 356)
▸ Concurrency utilities (JSR 236)
▸ JSON Binding API (JSR 367)
▸ Bean Validation (JSR 303)
▸ JPA (JSR 338)
▸ JMS (JSR 914)
▸ JTA/JCA
▸ Dependency Injection (JSR 330)
▸ Common Annotations (JSR 250)
17
28. Update your Jakarta EE
version in pom.xml
Java EE pom.xml Jakarta EE pom.xml
29
29. Rename javax
imports
▸ All javax.* package namespaces must be
renamed to jakarta.* namespaces in your Java
source code
▹ Java EE 10 application container is no
longer backward compatible with Java EE
applications.
30
30. Update XML Schema
namespaces & version
▸ Rename JCP namespace from “http://xmlns.jcp.org” to
Jakarta EE namespace “https://jakarta.ee/”
▸ Jakarta EE namespace includes XSD version numbers
▸ Common API affected:
▹ Servlet (web.xml), JPA (persistence.ml), CDI
(beans.xml), Bean validations (validations.xml), Batch
(batch.xml), Taglibs (JSTL), JSF (faces-config.xml)
31
31. Rename files and properties
prefixed with javax
▸ XML configuration files with property names
that have javax prefix.
▸ Bootstrapping files that have names prefixed
with javax.
▹ E.g. CDI service extension. Rename
javax.enterprise.inject.spi.Extension to
jakarta.enterprise.inject.spi.Extension
32
36. API and package
renaming.
▸ It’s cumbersome to rename packages manually.
A good IDE (that has Jakarta EE 10 support), like
IntelliJ, Visual Studio Code, etc., helps.
37
37. Dependency
management
▸ Jakarta EE APIs and platforms are upgraded to
latest versions to ensure compatibility (Jakarta
EE 10 is no exception)
▸ Third party libraries and frameworks might face
their own migration challenges in order to be
compatible with Jakarta EE 10
38
38. API deprecation and
Removal
▸ Certain Java EE applications can have APIs that
are removed in Jakarta EE 10
▸ Identify and replace deprecated APIs with
Jakarta EE 10 equivalent/counterparts can be
cumbersome.
39
40. Enhanced
compatibility
▸ Jakarta EE 10 maintains the backward
compatibility with Java EE (outside of
namespace changes). This ensures that
existing Java EE applications can be migrated
to Jakarta EE 10 without extensive code
changes.
41
41. OpenRewrite
▸ Helps with source code refactoring for
framework migration.
▸ https://docs.openrewrite.org/
42
43. Cloud-Native ready
▸ Jakarta EE 10 embraces the evolving landscape
of cloud-native architectures and
microservices.
▸ Your monolith application can be migrated to
be cloud-native approach and take full
advantage of cloud-native technologies and
practices.
44