[Discussion] Supporting Jakarta EE 9+ Servlet API

[eclipse-rap]

[Discussion] Supporting Jakarta EE 9+ Servlet API

[ifurnadjiev]

I want to share something about Jakarta EE 9 support in RAP. I've tested one tool provided by Apache Tomcat [1, 2] (Apache Tomcat migration tool for Jakarta EE) with the latest RAP release. There are actually minor problems to convert a war file (RAP app) based on javax namespace to jakarta namespace.
I've opened an issues against Equinox [3] and Tomcat [4].
In general, you can use this tool to make RAP application compatible with Jakarta EE 9. The simplest way is to drop the war file not in Tomcat 10 "webapps" folder, but in "webapps-javaee" and the migration tool will do the job automatically.

I hope that the blocking issue will be fixed soon.

[1] https://tomcat.apache.org/download-migration.cgi
[2] https://github.com/apache/tomcat-jakartaee-migration
[3] eclipse-equinox/equinox#164
[4] apache/tomcat-jakartaee-migration#39

[SteffGo]

I would like to point out that at the moment, it's not possible to create a Eclipse RAP application as spring boot V3 application. Starting with version 3.0, spring boot is using jakarta.* instead of javax.*.

[bwolff]

To answer on the last post from @mknauer here: https://www.eclipse.org/forums/index.php?t=msg&th=1111838&goto=1855689&#msg_1855689

I agree, such a move would involve a lot of work and coordination with other projects. Thanks for the insights from the Eclipse platform people. It would also be interesting to learn from other Eclipse projects that rely more heavily on the "legacy EE" APIs.

Imho, the "legacy" Java EE APIs will probably become the new Java 8 ;). They will live on and will be supported for many years to come. In the RAP/RWT context, I see the risk to navigate into a "dead-end", or at least be restricted from using it together with Tomcat 10+ and Jetty 11+, thus restricting usage in more and more scenarios in the long-term.

Regarding a compatibility layer that would require no code changes: I'm not an IT lawyer, but I guess that won't be possible due to legal restrictions on using the javax.servlet namespace, which was the reason for the change to jakarta.servet in the first place ;).

In any case, I'm happy to continuing the discussion here :).

[bwolff]

Thanks a lot for sharing your efforts @ifurnadjiev!

From what I understand, the migration tool takes a fully built artefact (WAR file) and converts it ad-hoc from "javax." to "jakarta." namespace. At least that will allow to deploy RAP apps on Tomcat 10+ (not taking into considerations any deprecations in the Jakarta EE APIs in the future).

This leaves the "issue" that you still have to write the code against the javax APIs. However, since RAP is part of Eclipse, we should probably just wait until the Eclipse platform moves to the jakarta APIs. I cannot imagine that this will take very long, but let's see.

In the meantime, the most pragmatic approach for my use-case (using RWT standalone in a non-osgi environment along with other jakarta-based dependencies) would be to fork the RAP sources and migrate the required bundles to the jakarta API at the source level. That should at least unblock me until the Eclipse platform moves to jakarta.

[ifurnadjiev]

@bwolff Sure. That's only a temporary solution for those, needed RAP running on Jakarta EE 9 immediately.

[theanuradha]

Spring Boot V3 migration blocking due to using jakarta.* instead of javax.*.

[TheLawful]

We too have a complex RAP application as the final blocker at migration of our platform to Jakarta. The migration tool works surprisingly well on Windows (a lengthy error log dealing with jakarta.servlet-api is written to /work/ but it works anyway), but leads to a complete mess on Linux, with classloader issues and version parsing conflicts of all kinds, using Tomcat 10.1.11 and exactly the same app. After several days of frustrating experiments, going down to Equinox and finally, OSGI HttpService, I'm losing my hope we could get it running at all. Some of the comments concerning Jakarta EE on the Equinox project* pointing at the outdated OSGI specifications which obviously dictate javax.*, Servlet API 2.1 and all don't leave me with much hope. My current estimate is that the Eclipse platform will never be migrated to Jakarta, even if Eclipse Foundation is the maintainer of that standard. Bummer. Nice job, Oracle, you killed RAP. Or what are the options?

*eclipse-equinox/equinox#183, follow the links there.
osgi/osgi#551

[jensborrmann]

The next external factor that seems to complicate things is the evolution of the JakartaEE APIs.

Especially the servlet API has some (minor) breaking changes in JakartaEE 10. This compromises/destroys the ability to work on the bytecode via transformations.

We haven't checked yet if this has become a showstopper yet. But it's obvious that without a real migration of the Eclipse platform, this won't work one day.