Converting ActiveMQ to Jakarta (Part 1)

Jakarta, formerly the Java Enterprise Edition (Java EE or J2EE), is the standardization of many important APIs used in enterprise and mobile Java applications. These standardized APIs allow coders to write applications with support for features such as interacting with data in databases, transmitting or retrieving data from a queue, collaborating with web services, or developing web-based applications.

The Jakarta standards and releases operate under the umbrella of the Eclipse Foundation's project framework. This foundation, a highly respected open-source organization, is responsible for various significant Java-based technologies, including a complete Java distribution. These key specifications are now set to evolve quicker and introduce new features more rapidly than when under the previous organization structure.

The timeline for adopting the new version of the Jakarta EE APIs is primarily driven by the popular Spring framework and Spring Boot runtime. Spring established that all applications will be using Java JDK 17, and Jakarta will form the foundation for Spring version 6 and Spring Boot version 3. Free, open-source support for Spring version 5 and Spring Boot version 2 ends at the end of 2023. Spring’s extensive connections to other popular Java frameworks are rippling through the entire Java ecosystem to jumpstart the transition over the next year.

Code Changes Ahead

For enterprise developers, the advent of new Spring 6 and Spring Boot 3 projects will spotlight Jakarta as the primary focus, necessitating the update of any existing projects accordingly. With the decoupling of Java from Oracle, the namespace of the APIs has transitioned from 'javax' to 'jakarta'. Consequently, Java code leveraging these specifications requires updates. For instance, applications utilizing the Persistence specification (or JPA) for storing and fetching data from a database will need to undergo changes.    

import javax.persistence.Query;

To:

import jakarta.persistence.Query;

For applications using the Jakarta Messaging specification (aka JMS) to send and receive messages using queues:

import javax.jms.Message;

To:

import jakarta.jms.Message;

Small projects and micro-services should migrate very quickly.  After the initial one or two conversions, developers should be proficient enough to migrate any code base with minimal effort. However, larger projects may require a deeper investment of effort, as any existing technical debt could potentially magnify the scope of tasks that need to be addressed.

Moving Forward

The Java ecosystem is quickly evolving, creating enormous value for developers and, ultimately, organizations utilizing Java for their applications. 

In addition to Jakarta, the Java language itself is getting substantial updates — such as Lambda expressions, Virtual Thread (Project Loom), Records, and many performance and optimization enhancements to Java execution — which are improving the developer experience and lowering cloud bills. These improvements introduce exciting features inspired by languages like Scala and Kotlin that had been popular due to certain developer-centric functionalities but were not the best choice for enterprises due to the limited availability of developers when compared to Java.

With a rich ecosystem of tools and a massive pool of available developer talent, these features will improve performance, lower costs, and attract talent with improved developer experience. This innovation and improvement to standards and frameworks will keep the Java ecosystem thriving for years.

Here at HYTE, we develop our products using Java, utilizing many specifications noted in this blog post. Stay tuned for insights on HYTE's experiences in updating our products for Jakarta and our contributions to Open Source projects — including the substantial amount of work needed to complete the update of Apache ActiveMQ to Jakarta EE APIs.