Blogs

TL;DR

Liferay believes that overcoming the javax renaming scenario is predicated on tooling being the highest priority.

Proposal 1 (Big Bang) is the better choice provided that the aforementioned tooling exists. Otherwise, Proposal 2 (Incremental Change) is the better choice.

Whatever the tooling, the Jakarta EE Strategic and Participating Members as well as the open source community all have a role to play.

One of the big value propositions of Java EE was the stability of the APIs and long-term application server support. Let's do our best to build on that legacy.

Related blog post: Should Eclipse MicroProfile join Jakarta EE? by Ray Augé.

Background

On May 19, 2019 Mike Milinkovich of the Eclipse Foundation posted a blog titled Update on Jakarta EE Rights to Java Trademarks in which he wrote that the Eclipse Foundation and Oracle agreed that the javax package namespace could not be evolved by the Jakarta EE community.

Soon afterwards, David Blevins of Tomitribe kindly wrote a document titled Transitioning Jakarta EE to the jakarta namespace in which he lists the benefits and drawbacks of Proposal 1 (Big Bang) and Proposal 2 (Incremental Change). Users in the Jakarta EE mailing lists soon began discussing the issue in the following threads:

• Transitioning Jakarta EE to the jakarta namespace
• Support for the Incremental approach to Jakarta EE package renaming
• Java EE Guardians Statement on Oracle/Eclipse Agreement

In addition, there have been a variety of blog entries written by proponents of Proposal 1 as well as those advocating Proposal 2.

Liferay's Position

After discussing it with Liferay's management, I would like to take this opportunity to communicate Liferay's position regarding this issue:

The primary concern of Liferay's customers and open source community would undoubtedly be that of binary backward compatibility. Although this can be achieved more easily in Proposal 2, Liferay believes that Proposal 1 would be the better choice provided that the following words in Proposal 1 are fulfilled:

"It is envisioned binary compatibility can be achieved and offered by implementations via tooling that performs bytecode modification at either build-time, deploy-time or runtime."

The secondary concern would be that of source code tooling.

In other words, if Proposal 1 wins, binary backward compatibility (our top concern) and source code tooling (our secondary concern) can only be achieved with the help of outstanding tooling. Until such tooling exists, adoption of Jakarta EE 9+ will be limited to new application development. The only exception would be migration of projects at the source code level using simple global search-and-replace techniques.

Backward Compatibility Tooling

As BJ Hargrave points out in his blog, it's not simply a change from javax -> jakarta that we are concerned with. It's also XML schema namespaces and META-INF/services ServiceLoader files that contain javax as a filename prefix. There are doubtless many other corner cases as well.

As Proposal 1 points out, binary backward compatibility tooling would occur at build-time, or alternatively at deploy-time/runtime.

The build-time tooling could take ideas from the maven-shade-plugin such as the class relocation feature. It would be necessary to provide build-time tooling for Maven and Gradle at a minimum.

It would be in the business interests of application server vendors to focus on deploy-time and runtime tooling, and running the Jakarta EE TCK in "legacy" javax mode should provide good cross-application-server testing.

Source Code Tooling

In addition to backward compatibility tooling, there is also the issue of source code tooling. This would fall most naturally into the category of IDE support, but could include command-line tools as well. It would be the responsibility of source code tools to automatically fix import statements as well as manipulate pom.xml and/or build.gradle descriptors.

In order to minimize the complexity of source code migration, Liferay believes that only top-level package naming should take place. In other words, we are not in favor of renaming sub-packages as part of the work planned for Jakarta 9.