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



On Tue, May 7, 2019 at 10:52 AM Ivan St. Ivanov <ivan.st.ivanov@xxxxxxxxx> wrote:
Hi everyone!

To start with, I am a Java EE user and small scale developer and not developing Java EE servers or supporting huge customers or code bases.

I would opt for option 1 - the so called "Big bang". I phrased it as "so called" because it is a real big bang, but not for the customers. It's a big bang for the platform vendors.

What I mean is, when a customer gets a new release of an application server, they do not necessarily upgrade their app to the latest Java EE release supported by that application server They rely on the fact that the server will support even their J2EE apps forever. If a customers wants to upgrade their apps to the new specs coming with the new EE release, the amount of work usually goes much beyond simple renaming of imports. 

Just put it for an example in the perspective of JSF. You may have applications that you have written 10 years ago, which would look like much differently than contemporary JSF books, blogs and examples showcase. But still they are supported by the application servers. And the decision to migrate those apps to latest and greatest JSF goes far beyond simple renaming of lifecycle scope imports. So we already have migration effort all over our specs, but it was not put that dramatically so far.

I think supporting Java EE has never been out of scope for all the vendors here. Either formally via Legacy Profile as proposed by Richard or informally by byte code modification, I hope everyone is already elaborating the possible options. But this will be the biggest work to be done with this transition in my eyes. And not reworking existing apps.

But again, that from the point of view of a person that just develops small to medium scale apps and does not develop the app server or support J2EE apps anymore.

I'm with Ivan. Perhaps mine is a naive concern. As I see it the main problem will manifest from the interactions between specifications and the non-app-server developer's attempt to adopt specs piecemeal.

Will vendors spend any amount of time working on piecemeal support of mixing jakarata and javax?

If not, the likely hood that an app can replace some but not all of the javax API usages will be low. This translates to all upstream application dependencies.

I realize there was some early hand waving about binary compatibility but I'm quite concerned about what that means in reality.

- Ray
 

Cheers,
Ivan

On Tue, May 7, 2019 at 5:19 PM 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
_______________________________________________
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


--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

Back to the top