Very good overview of the possible implementations for compatibility.
Questions which come to my mind:
- Is there a need to deploy applications to one application server instance using both APIs?
I think so. I can imagine many users will want to limit the number of things they change in their release plans, so they may want to transition the exact same application from an EE8 to an EE9 deployment, perhaps node by node. Thus being able to deploy the exact same application to both environments can be beneficial.
- Do we need an application server which is Java EE and Jakarta EE compatible at runtime?
If you want bug for bug compatibility with EE8 into the future, then some runtime solution is necessary - to have an EE8 runtime actually running. The only other driver for runtime compatibility modes I see is to free EE9+ from having to keep EE8 behaviours and APIs. A wrapper approach can assist with this where as a translation approach cannot.
- Is there a need to have an application server being Java EE and Jakarta EE backwards compatible for a long long time? Should this be specified or should vendors decide on their own?
Define long :)
I think LTS is probably vender by vender - We still have some commercial support for our Servlet 2.4 server! However, given the uncertainty that this change is probably going to cause, I think some vendor pledges for some reasonable duration of support for EE8 deployment may be helpful.
cheers
