|
You just made my evening. It is awesome to hear both Jakarta EE 8
and Jakarta EE 9 will be quick. Hopefully right after that we can
start delivering innovation via Jakarta EE.
On 5/7/2019 7:21 PM, Kevin Sutter
wrote:
Rudy,
Jakarta EE 8 needs to be equivalent to Java EE 8.
This will demonstrate that everything has successfully been
transferred to Eclipse and that we have used all of the
processes (JESP, TCK, etc) to create and validate this
release. Introducing API changes into this Jakarta EE 8
release would complicate this process.
We want Jakarta EE 9 to come out right on the
heels of Jakarta EE 8. Waiting until late 2020 is not an
option, in our opinion.
-----
Original message -----
From: Rudy De Busscher <rdebusscher@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 1:46 AM
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
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
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
|
