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?
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.
cheers
