Skip to main content
[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
Thanks to David for starting this post and for all of the community insight, thus far, on this important topic.  I tend to lean towards "Proposal #1" for performing a big-bang transition.  I believe it will be the *least* confusing option for the entire customer and community base.  However, I do also like Richard's "Legacy Profile" naming convention.  

If we take a step back and look through the eyes of all customers that do not follow these topics religiously, they will be confused by the proposed Jakarta EE 8, Jakarta EE 9,  Jakarta EE 10 transition.  If nothing but namespace changes (and obvious container changes) are made when moving to Jakarta EE 9, then I fear many customers will simply "skip" that release and jump to Jakarta EE 10 when it arrives...making the "big move" to a new container and likely many code changes with that release.  I think it makes sense to introduce some key new enhancements in Jakarta EE 9 to show evolution in the platform, and at the same time introduce the new namespace...not to mention release this as soon as reasonably possible on the heels of Jakarta EE 8.  That said, in this sense it may be helpful to name or label Jakarta EE 8 as a "Legacy Profile".

Best Regards

On Tue, May 7, 2019 at 9:19 AM carlos andres de la rosa <kusanagi12002@xxxxxxxxx> wrote:
Hello folks,

The Brandon idea "@Deprecated" mixed with the "legacy profile"  can be pretty helpful to have better backward compatibility due we can have a profile that allows gradually deprecate previous APIs versions, the profile ensure that we can have like a snapshot in which can start to work deprecating incrementally,
 but in legal terms that brandon mention will be violating the agreement?

Cheers

Carlos

On Tue, May 7, 2019 at 3:58 PM Brandon Heck <brandon.heck@xxxxxxxxx> wrote:
I apologize if this was captured in one of the options and I simply failed to interpret it correctly, but could the existing javax APIs be frozen and left in for at least one, or preferably two, releases of Jakarta EE? Can the @Deprecated annotation be added without violating the agreement? The APIs could be copied over to the jakartaee package and new functionality and API changes can be made there. This would allow existing apps to continue to run on newer implementations without making disruptive changes while also allowing developers that want to move fast to utilize the new package and have access to the new functionality. Implementers could also have a large portion the javax APIs call through to the new jakartaee APIs.


On Mon, May 6, 2019 at 9:33 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
Great to hear from you!

> On May 6, 2019, at 7:22 PM, Hildeberto Mendonça <me@xxxxxxxxxxxxxx> wrote:
>
> A way to add value is not increasing the maintenance cost and preserving backwards compatibility. I'm afraid Proposal 1 would break these two values.
> I would prefer Proposal 2 if jakarta worked as a wrapper around javax, preserving the same interfaces, reusing what is already there and innovating on the wrapper side.

Both proposals involve what you would call "a wrapper" and have the same basic backwards compatibility challenge of having to figure out how to make old apps run.

The primary place they differ is:

 - do we break compatibility bit by bit over time in an as-needed basis
 - do we break compatibility in one shot and get it over with

The primary question here is as a user how do you want to deal with migrating and potential compatibility issues:

 - bit by bit over time
 - in one shot

Knowing neither path frees you from having to absorb a backwards incompatible change and the solutions would be the same, which timeline is your preferred?


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


--

Carlos Andres De La Rosa | Technical Architect

Mobile: +32465445631  

Skype: carlosa.dlr

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

Back to the top