The move from Java EE to Jakarta EE means some updating of package names. Example: what was “javax.servlet.*” in Java EE now is “jakarta.servlet.*” in Jakarta EE. – Maybe you already have experienced this when installing existing applications with Tomcat 10 – having received corresponding ClassNotFound-exceptions…
CaptainCasa as framework now comes in two variants:
- The Java EE variant (“default” variant)
- The Jakarta EE variant
You find corresponding downloads both on our download page and in our Maven repository.
Jakarta EE is still quite young. Nearly all Java server projects are based on Java EE – and moving an application from Java EE to Jakarta EE means quite high effort: you not only have to do some renaming within your own classes, but also need to update all your dependencies which internally reference corresponding “javax.*” classes. – Many projects are using Spring, which uses Java EE, and which is not available for Jakarta EE currently.
For all existing users of CaptainCasa:
- Is there anything to do on your side? – No! Just continue to use the “Java EE” variant of CaptainCasa.
- Should you plan to move to Jakarta EE? – There is no requirement currently from a CaptainCasa framework perspective. The Java EE and the Jakarta EE variants are the same. Actually the Jakarta EE variant is automatically built from the Java EE variant.
- Is the move to Jakarta EE simple? – No. It’s definitely not a “by the way”-issue. Updating your code to use the new package names – this is simple. But then comes the long list of libraries that you depend on and which also need to be updated…
For new users of CaptainCasa:
- Should you start with Jakarta EE instead of Java EE? – We can only say: from a CaptainCasa perspective you can choose either the one or the other. So your decision is independent from the CaptainCasa framework. – If you plan to use Spring: no chance, currently, to go with Jakarta EE, so stay with Java EE.
