David,
thanks for starting to curate the feedback. However I take issue with the following:
It is envisioned binary compatibility can be achieved and offered by implementations via tooling that performs bytecode modification at either build-time, deploy-time or runtime. While there are open questions and considerations in this area, the primary goal of the discussion that must conclude is how do we move forward with future modifications to the APIs themselves.
Essentially you are suggesting that these discussion should exclude consideration of one of the most significant impacts of this name change. This is like voting for Brexit without have any idea what a Brexit would look like or how it can be implemented!
If you look through the responses here and in other forums, it is apparent that there are lots of different views of how legacy code will/can be handled (yes I note some don't like the term legacy being used, but that is essentially what all javax based projects have become the moment the ability to evolve that name space was lost).
<FUD>
Is the expectation of our users end vendors that javax code will be able to be run only in different server instances? in different contexts on the same server? Within the same context? Will cross context dispatch be supported? Will deployment descriptors using the
http://xmlns.jcp.org/xml/ns/javaee XSDs be able to be deployed in renamed containers if they use renamed APIs. What startup and runtime impacts will be imposed on javax code run in binary compatible mode? What is the latency and carbon foot print impacts of these adaptions (yes I'm serious here, the decisions we make here will have an impact!)
What is the expectation of future deployments of such binary compatible code? Initially these tools will be able to simple map the name spaces to the new jakarta API implementations. However, as the jakarta APIs and behaviours evolve, then simple name mapping will not be sufficient as it will change behaviours. Creating a parallel runtime that preserves legacy behaviours will be a significant cost and the effort required will greatly depend on what level of isolation of legacy code is expected.
</FUD>
I don't expect that there is any one answer to these questions, as I doubt we will be able to make all our users think with one mind. It is probable that we vendors are going to have to support most options: legacy javax only servers; jakarta only servers; tools to statically or dynamically convert legacy code; mixed runtimes with adaption layers (back and forth). We will lose users to other technologies as a result of this. I doubt we will attract many new users unless we do something spectacular! This is going to be the end of some projects, companies and careers and it is going to create new projects, companies and careers.
We are facing significant churn no matter what we do, but let's not pretend that churn is not there or that our decisions cannot influence the extent and/or duration of that churn.
tl;dr; binary compatibility is a primary consideration of this discussion.
--
