[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace

David et al,

I'm currently travelling so have not had a lot of time to well order my thoughts on defining a topology of binary compatibility modes... at least not enough for a pull request. ÂHowever, I have a google doc in which I've put down my initial thoughts and I welcome any comments/feedback to help get it to a point it can be made into a PR (or discarded as not worthwhile).

https://docs.google.com/document/d/1bNJkqQLJL1RY4Bx6k7BMvhaoCxh9-dzq8v-kmHeUxis/edit?usp=sharing

cheers



On Thu, 9 May 2019 at 17:53, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
On May 9, 2019, at 12:28 AM, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:


On Wed, 8 May 2019 at 22:46, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
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

_______________________________________________
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


--
Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com