Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] Jakarta EE 8 compatibility
A separate specification for backward compatibility could work.  It could be designated as a profile and adoption would not be required.  It would remain fixed with only service releases as absolutely necessary and would essentially encompass Java EE 8 backward compatibility.  With that vendors who wanted/needed to support backward compatibility could do so with a verified (by TCK) profile.  Meanwhile, everyone can continue to evolve the new Jakarta EE platform.  

On Mon, Apr 22, 2019 at 1:03 AM Kazumura, Kenji <kzr@xxxxxxxxxxxxxx> wrote:

 

I mostly agree with Steve.

 

Regarding the backward compatibility issue,

I think it should be defined in the specification.

If it is a vendor specific effort, the customers might be confused.

For example, vendor A claims A’s product is backward compatible with Jakarta EE 8,

and vendor B also claims B’s product is backward compatible Jakarta EE 8.

But actually the meaning of ‘backward compatible with Jakarta EE 8’ is different between vendor A and B.

 

 

-Kenji Kazumura

 

 

From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx [mailto:jakarta.ee-spec.committee-bounces@xxxxxxxxxxx] On Behalf Of Bill Shannon
Sent: Saturday, April 20, 2019 3:03 AM
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>; Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec.committee] Jakarta EE 8 compatibility

 

I generally agree with Steve.

Plus, I strongly discourage trying to manage multiple releases in parallel.  This community needs a proven track record of getting releases out on time before trying something as complex as multiple parallel releases.

Steve Millidge (Payara) wrote on 4/19/19 12:16 AM:

My thoughts on this are;

 

There is only a small amount of tolerance out there for the pain of migration from 1 release to another. The outline you have below has the potential to require users of Jakarta EE 8 to take a hit twice. First to migrate to Jakarta EE 9 as they will have to port to Java 11 and cope with the loss of deprecated apis they may be using. Then they will also face a large migration effort to move to Jakarta EE 10. Many will think we are signalling that the two step approach is the best approach by having the two releases. I feel this will drain goodwill.

 

I think there are advantages to take the pain in one big hit as I feel you can build a narrative that justifies this from the  points below.

 

First Jakarta EE 8 will be released and that does provide backward compatibility to Java EE 8 and will be supported by products for many years therefore there is your continuity and LTS version.

 

Second a change forced upon us by lawyers to move the namespace to Jakarta. Something we can only say once and is “our hands are tied”. This point can also be expanded to cover why a namespace drip change is worse than a big bang shift.  

 

Third there is the hit to move to Java 11 and all that entails including full support for JPMS etc. in JakartaEE.Next

 

Fourth the drive to reduce footprint and legacy for the Cloud Native era justifies deprecating and removing a lot of old apis.

 

Fifth to increase innovation first by moving namespace this gives the project teams space to innovate freely at the Eclipse Foundation, secondly ditching legacy and backwards compatibility provides the freedom for new players to enter the market and new forms of runtime to be created.

 

Sixth this will take time so JakartaEE.Next the next LTS is due end of 2020(?) and time will also enable vendors to create tools that will help users migrate to the latest LTS.

 

Finally outline an LTS release strategy with intermediary releases and a fixed cadence whereby Jakarta EE 8 is labelled as the first LTS and put together a roadmap of future releases which is compelling and says stick with us through this journey as the future is exciting.

 

 

Steve

 

From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> On Behalf Of Mike Milinkovich
Sent: 18 April 2019 20:30
To: jakarta.ee-spec.committee@xxxxxxxxxxx
Subject: Re: [jakarta.ee-spec.committee] Jakarta EE 8 compatibility

 

All,

I have been following this thread with great interest. I have to admit that I am finding Steve Millidge's arguments about biting the bullet and switching everything to the jakarta namespace compelling. But at the same time breaking every customer's existing Java EE application is a not to be done lightly.

But I have noticed that there are some assumptions implicit in what people are saying that should be discussed explicitly. Those assumptions are basically about the overarching intent of each of the Jakarta EE X releases.

I would like to throw out the following strawman proposal for the main themes for the next couple of releases for your consideration. Even if everyone thinks that this a completely stupid idea, I do think that there is value is achieving consensus at the level of release "themes" before continuing the debate on release content. I was also say that I think that it is at least plausible that some amount of parallel development is possible with these suggestions.

Releases and themes

  1. Jakarta EE 8: As soon as possible in 2019 (July/August?)
    • For all extents and purposes technically identical to Java EE 8, but licensed under the Jakarta EE licensing regime, rather than the JCP's.
      • Indicator of success is Payara (and ideally Apache TomEE and others) are using the sailing ship logo.
  1. Jakarta EE 9: TBC, but plausibly within 2019
    • Deprecate and remove unwanted APIs/specs following the JESP process
    • Continue use of the javax namespace for the remaining specifications, Likely the last release to ever make use of javax.
    • Port to Java SE 11
    • Basically, this becomes the first Jakarta EE LTS release
  1. Jakarta EE 10: TBC
    • Switch to jakarta namespace
    • Perhaps break backwards compatibility
    • Perhaps leverage some sort of application transformation tool to map applications' use of javax to jakarta

If this approach were to be adopted, I would suggest that we open Spec Projects for Jakarta EE 9 and 10 simultaneously in late Q2.

Please adjust your phasers down to stun :)

 



_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee

 

_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee


--

Back to the top