I've added a document here that is hopefully so bad it enrages someone to create a better one :)
Well I'm not exactly enraged by it.... but it does kind of miss the issues I'm concerned about. I'm not so concerned about the technology that will be used to achieved binary compatibility.... but what does binary compatibility actually mean and what are the impacts of it?
My intention was to motivate you to help fill out that doc to cover the issues you're concerned about.
Are you up for helping develop the backwards compatibility concept?
As Bill Shannon said:
100% compatibility is probably impossible. We're going to need
to decide what level is acceptable.
He then raises questions of can old and new APIs be mixed an matched. One of my big questions about any compatibility mode is how does it change over time? Ie on day 1 when the behaviour of the jakarta.* version is identical, then a simple renaming of deployed java.* code will not produce any behaviour changes. However, over time, as specs evolve, the jakarta.* behaviours will change. Does binary compatibility mean that we map java.* deployments to the new behaviours (if so, that's a bigger constraint on future evolution of the specs), or do we maintain bug-for-bug behaviours for javax.* deployments?
So I like Scott Stark's suggestion of a "taxonomy of compatibility modes" and I suggest that if he does that, then your backwards-compatibilty document should be amended with it. It may be that different vendors decide to implement different compatibility modes, so have a taxonomy would be good to explore/discuss/explain the impacts on users.
I agree with you 100%. Five more emails of awesome points in, and I'll still probably agree with you :)
If we want to mobilize people into understanding the options and tradeoffs for backwards compatibility so they can have a vote or influence over the choice, then we need to start writing stuff like this down. Ideally soon so people can be thinking a few steps ahead.
If you or anyone can help in that regards, that'd be amazing.
A doc of options with pros/cons is great. Doesn't have to be complete, just needs to be enough to get the ball rolling.
-David
