This tension between compatibility and trying to make a decision on how an initial move away from javax namespace APIs keeps coming up, and during today's spec committee call this was brought up and it was suggested that perhaps we need to define a taxonomy of compatibility modes, as Dan Bandera termed it, and relate those modes to the namespace change options. I was going to try to take a stab at doing this. As much as we would like to make the namespace change approach separable from compatibility concerns, unless that is clearly illustrated as possible they will need to be treated together as that is how most people are viewing this javax to jakarta transition issue.
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!
I never said exclude. We can talk about anything we like just as long as we also make sure to reach a decision on how to handle the namespace change in the time we have. As you point out, reaching a decision on that goal will logically involve a lot of groundwork.
Is that clearer and more in line with your thoughts?
-David
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
