pixel - Fotolia
What's in a name? What developers can expect in Jakarta EE 9
What Oracle called the Java EE API is now called Jakarta EE API under the Eclipse Foundation. Here's what developers can expect in the Jakarta EE 9 release.
The Java EE API, a reference standard for Java software development for nearly 20 years, was rebranded to Jakarta EE 9 in early December as part of its first full release while under the purview of the Eclipse Foundation.
Java EE was originally conceived by Sun Microsystems and subsequently curated by Oracle. Oracle donated the code in 2017 to the Eclipse Foundation, an organization that manages hundreds of open source projects. Beyond rebranding, software engineers won't have to grapple with monumental changes to the code itself. In fact, though everything changes, nothing changes at all.
What's new in Jakarta EE 9
Mike Milinkovich, executive director of the Eclipse Foundation, referred to Jakarta EE 9 as a "constrained release." He said the foundation's goal was to simply change package names with the word javax.* to jakarta.*.
"The fact that we did this release in a way that was really constrained … was a great decision by the community," he said. Milinkovich cited how the Eclipse Foundation nicknamed the name space change as "the big bang."
In Jakarta EE 9, the java.servlet.GenericServlet class is now jakarta.servlet.GenericServlet. The new release won't add any properties, remove any deprecated methods or fix any bugs. However, while the only change is the name, it applies to every class, interface and enum in the specification.
The change is necessary largely due to legal reasons. While Oracle donated the specification to Eclipse, it still owns the Java trademark. The name change also represents a clean split between old and new.
Potential Jakarta EE 9 issues
Vendors who provide application servers that use Java EE APIs will need to re-release their software to support Jakarta EE. But Milinkovich said he is confident that the vendors will catch up.
"The ecosystem is going to move forward as the platform moves forward," he said. "And one of the things that we are most optimistic about is the fact that all of the vendors for the application servers are committed to moving this forward."
From the developer perspective, engineers will need to rewrite applications that contain Java EE component references when they relocate to a purely Jakarta-EE-based server. Also, application development and deployment tooling must catch up.
For example, if you create a Java Servlet in the Eclipse development IDE, it defaults to the Java EE-based javax classes, even if you've configured the Jakarta EE-compliant Tomcat 10 as the application's Java runtime. It flags errors that don't exist and will indicate broken builds when they also don't exist.
What Jakarta EE 9 means for development
For Bert Jan Schrijver, CTO at OpenValue, a Dutch software developer, Jakarta EE 9 represents mainly a tooling release, since there aren't any new features targeted at developers.
"As a developer, the main reason to switch is to migrate your application to Jakarta EE 9 and be prepared for the new things that are coming in Jakarta EE 10," he said. "But, you're also free to wait and jump to Jakarta EE 10 [directly], skipping 9."
Schrijver said that while he prefers to take small steps -- migrate to 9 and then to 10 -- any decision will depend on the situation. "If you're running on an application server that is not yet supporting Jakarta EE 9, then, as a developer, there is no point in migrating," he said.
Schrijver said the decision to limit the initial release of Jakarta EE 9 to a name change has simplified things for the development community. If Eclipse added new functions on top of the name changes, it would lead to more complex troubleshooting.
