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
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.