[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

In my head I separate two things:

1) a namespace change
The namespace change is the biggest deal and whichever choice we make regarding moving from javax to jakarta it needs to be done in a way that brings the existing Java EE ecosystem forward without making people choose to a) support Jakarta EE 8 or Jakarata EE 9 b) without requiring the whole world to move forward at the same speed. As stated several times a namespace change is relatively simple to handle at runtime or build time since we are just talking about updating the constant pool references, However I donât think we can say âthis is a vendor decisionâ of course supporting Jakarta EE 8 or Jakarta EE 9 in an individual runtime is a choice an implementation should be free to make, but I think the Jakarta EE community at Eclipse needs to look at making the developer migration experience virtually free for a namespace perspective (Iâd prefer free, but Iâm a realist). I wrote more detailed thoughts up on a blog post here: https://openliberty.io/blog/2019/05/08/jakarta-ee-naming.html but essentially I think we need to support mixing and matching Java EE and Jakarta EE at build time in a consistent way to remove barriers that make the Jakarta EE community smaller than the Java EE one.

2) Behaviour changes, removing methods etc
There has always been an element of this in moving from one Java EE level to another. I donât think we should be doing anything that will prevent older Java EE apps forward. I speak regularly to people who have 15 year old Java EE applications and they are going to want to be able to continue running those in future and while we can support that with Liberty because we already support Java EE 7 & 8, I think the people who own those applications will need and want a future for them.

Of course Iâm involved in implementing these things, so my view may be skewed somewhat by that, but I think the need for a frictionless move from Java EE to Jakarta EE is critical.

Thanks
Alasdair

On May 9, 2019, at 8: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?

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

 
--
_______________________________________________
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