[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

Actually,

Thinking about transition from Java 8 to Java 11 and so, we have to be very worried to lost compatibility? We can stand working for JavaEE7 and JavaEE8 like still now? and we begin to work with JakartaEE8 like a big and new bird flying in the new sky?

My 5 cents.

BR

@edivargas - CTO weex
Oracle/SUN Java Champion
JUG's: www.javaup.org.mx
Mobile (+52) 55 3334 9115
ÂÂÂÂÂÂ (+52) 55 7070 9866
Twitter/Google/Yahoo: edivargas
Facebook: https://www.facebook.com/EdivargasJVG


On Tue, May 7, 2019 at 12:46 AM Rudy De Busscher <rdebusscher@xxxxxxxxx> wrote:
Hi All,

The package name change needs to happen already in Jakarta EE 8.

If we wait until Jakarta EE 9 or later, hardly anyone will still use or consider Jakarta. When isÂJakarta EE 9 scheduled? Maybe end of 2020 or later? That means that in a period of 3 years or more we didn't release anything new. One of the rules is that you should only consider an open-source library which is 'active'. I do not think that we fall in that category if we do not release something useful in a 3 year period!

The fastest, but with a breaking change, is proposal 1 - Big Bang (but now and not within a year or so). Replacing the import statements in the application code or a java agent within the runtime are easy to do!.

Regards
Rudy

On Tue, 7 May 2019 at 06:16, Edwin Derks <ederks85@xxxxxxxxx> wrote:
Hi all,

and big thanks David for starting this thread! I also would like to share my thoughts and have done so at my blog. Whatever the path we are going to take with this transition, I will try to assist whereverÂI can.

Thanks,

Edwin

On Tue, 7 May 2019 at 04:33, 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
_______________________________________________
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