[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
- From: Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx>
- Date: Fri, 10 May 2019 06:55:10 -0500
- Delivered-to: firstname.lastname@example.org
I'm having trouble understanding the difference between Big Bang and Incremental proposals with regard to what I think is a key issue: The mixing of javax and jakarta namespaces in a single application.Â In the github proposal for Incremental, it says over and over again that the result would be mixed namespaces.Â But the Big Bang never says that yet it does say "Any packages not moved from javax to jakarta could be included in Jakarta EE, but would be forever frozen and never move to the jakarta namespace."Â Âwhich is exactly the same thing, right?Â So if Big Bang allows for mixing of namespaces why doesn't the proposal for that say so?Â What am I missing?
The cons for Incremental go a long way to arguing that this mixing is an issue, yet the Big Bang, if that proposal as written in github is followed, does not. I think we need to decide if Big Bang allows mixing or not. It's been my understanding that Big Bang moves EVERYTHING over not just what we think matters. That is also a key difference that seems to get lost with that one statement I quoted above.
I could have captured this in a JIRA ticket, I suppose, but I think it would simply be lost and never discussed.
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?
Yes - but it's taking me a while to come up with my own mental topology of options.Â ÂWe are working on some internal stuff at the moment and I'll try to generalise that andÂsend a PR in the next few days.
I agree with you 100%.Â Five more emails of awesome points in, and I'll still probably agree with you :)
Nah! Actually it is going to other way!Â ÂI started off pretty much opposed to the big bang rename, but now I'm tending to think we will never be able to avoid the consequences so ripping the bandaid off may well be best.Â ÂIt is a pity we will lose resources/time to innovate, but on the other hand a clean slate name space doesn't make great new APIs pop into existence either, nor exempt us from an obligation to deal with backwards/binary compatibility.Â Â As Bill says in his reply, changing the name space doesn't really change how we support version-to-version and if we really wish to breakÂ compatibility for some new ideas, there is plenty (infinite) of space under the jakarta.* top level for new APIs and we can applyÂ@deprecated to "legacy" ones if we choose to (hmmm perhaps "classic" might be better than "legacy":)Â Â
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.
Yep - I think defining transition strategies and technologies is key - for big bang and incremental.Â Â I'll try to roll the ball a little in the next few days and I promise you it wont be complete.
jakartaee-platform-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit