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
