This is essentially proposal 2 with a stated compatibility requirement. While the requirement for compatibility is being discussed, the spec committee wanted to separate out that discussion from initial feedback targeted toward just what type of move away from javax people wanted. Certainly compatibility requirements dovetail into this discussion, but depending on how it is implemented, it can be orthogonal.
For example, our servlet spec lead suggested that they could create a compatibility library that mapped the legacy javax.servlet classes onto the current jakarta.servlet APIs, and the container could do whatever wiring was needed to fill in the gaps.
Similarly there have been discussions of a variation of the maven shade plugin that mapped the legacy javax classes and resources onto the new versions so that the container implementations are only dealing with the new APIs.
I'll start by pointing
out that these are some of my own thoughts and do not represent any position
on the part of my employer.
One of the really
valuable parts of Java EE as a standard is the wide array of pluggable
third party implementations that are available. I worry that if we put
out a breaking spec change like package renames (you can't implement both
interface variants under a single implementation class due to details like
spec-defined concrete exception classes), that a number of third-party
implementations will simply never update to jakarta, and applications will
be torn between their dependencies vs taking advantage of improvements
in other specs at newer levels. Many applications will stay behind as well,
make attempts to mix different jakarta.* and javax.* technologies, or move
away from Java altogether. Some providers/applications/vendors which have
a desire to support both javax and jakarta will overcome the breaking changes,
but will do so at the cost of increased footprint.
There is another
option that should at least be considered. What if we just keep the javax
packages as they are and leave them alone, still fully part of Jakarta
with each subsequent release? Full compatibility would be maintained.
Enhancements could instead be made by parallel specs that introduce
individual interfaces under jakarta.*, but only as needed. Completely
new specs would of course be written under jakarta.*. Sure, there
is some inconvenience here (extra imports for users, maybe a need for creative
interface design in places, probably some unwanted limitations on changes
that can be made). However, that may be a small price to pay to avoid all
of the churn, confusion and trouble that would otherwise arise from having
duplicate implementations per package name, existing probably indefinitely
for as many of the third-party providers of resource adapters, JMS providers,
JPA providers, JSON-P/B providers... and so on, as are willing to provide
a jakarta.* variant.
