Javax to jakarta

dev
1

Has Lucee moved to using the jakarta.* name space from the javax.* name space?

2

nup, wanna help?

3

Maybe. Is it just a matter of changing the imports? Not sure how big a project that would be. I haven’t written java code in 20 years.

4

mostly, there’s a migration guide

I’m a cfml dev, dabbling in java to make Lucee cfml better

5

Do you have a link to this guide? I found this tool by Tomcat:

6

I’m not sure, @isapir knows much more about this stuff than me!

As Lucee uses it’s own bundled versions of these Libs, so @micstriit will need to make them available to Lucee before you can test any changes

7

I did a little research because I use Jetty as my servlet platform.

These platforms version have moved to the Jakarta namespace.

  • Tomcat 10
  • Jetty 11
  • GlassFish 6
  • WildFly ( JBOSS ) 21.0.0
8

Oracle donated the Java EE (Enterprise Edition) to the Eclipse foundation, but refused to allow use of the “Java” name. Because of that the Jakarta Project, which is the new name for Java EE, could not use the javax namespaces in future development.

There was a lot of back and fourth on how to move forward, and the decision was to make an initial release where the only change is in the namespace renaming from javax to jakarta.

Lucee does not bundle a version of these classes itself - they come from the Servlet Container, e.g. Tomcat or Jetty, but it references them in the code so for example the Lucee code references javax.servlet.ServletConfig at Lucee/CFMLServlet.java at 6.0 · lucee/Lucee · GitHub which is in the javax namespace, but in Jakarta it has been moved from javax.servlet.ServletConfig to jakarta.servlet.ServletConfig

So if you run this version of Lucee in Tomcat 9 which bundles the javax.* namespace everything is fine, but if you run it in Tomcat 10 which bundles the jakarta.* namespace everything breaks.

We can’t simply do a Find and Replace on the Lucee code yet because updating it for Jakarta EE (e.g. to run in Tomcat 10) would break it for Java EE (e.g. in Tomcat 9, 8.5, etc.).

So the first thing to do is to decide when we will make the switch, which must be a major version update, create a branch for that, and do it there.

9

p.s. The aforementioned Tomcat migration tool at Apache Tomcat® - Apache Tomcat Migration Tool for Jakarta EE Software Downloads does the translation from javax to jakarta at runtime via the magic of Java Class Loaders, so that might be a solution for those who want to run Lucee in Tomcat 10.

10

Interesting topic!

With Lucee 6 on the horizon (i.e. “a major version update”), it seems that this would be an appropriate window to “make the switch” … so I am curious if this is being considered and what the thoughts of the core team are on this topic? There are generally several years between major Lucee releases and I believe LTS for Java 11 ends sometime in 2023.

11

It’s definitely something to consider because at some point we will have to make the switch. So Lucee 6 is an opportunity but we could also go to Lucee 7 faster than usual because of this issue.

Java 11 is not a factor here as Java SE is unaffected and you can run either versions of EE with newer Java SE like 13, 15, 17, etc.

Personally I don’t like to rush with major upgrades of server software, so I am still running Tomcat 9 and plan to continue for a while before considering Tomcat 10.

So if we modify Lucee 6 for Jakarta I will be unable to use it until I’m ready to upgrade to Tomcat 10. OTOH given our past release cycles there’s a good chance that I’ll be ready to upgrade Tomcat by the time Lucee 6 is ready.

Since 5.3.8 is the last in the Lucee 5 version, that means that users will not benefit from new features until ready to upgrade to Lucee 6, so if we do decide to make Lucee 6 Jakarta EE compatible we should consider adding 5.3.9 or 5.4.0.

There are several routes here and each has its pros and cons.

1 Like