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

Brandon,
I'm not a lawyer, but my guess is that the addition of the @Deprecated annotation would be considered a change to the API and, thus, not allowed in the javax namespace.  We can broach the subject on our Steering committee call, but I'm guessing that will be the answer.

---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
 
 
----- Original message -----
From: Brandon Heck <brandon.heck@xxxxxxxxx>
Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc:
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
Date: Tue, May 7, 2019 9:58 AM
 
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
 


Back to the top