|
This seems reasonable enough to me. Thanks for sharing the
motivation. It is heartening to know the consensus is that Jakarta
EE 9 will not be a lengthy effort.
On 5/7/2019 11:37 PM, Kevin Sutter
wrote:
When the idea of Jakarta EE 9 was first floated,
it was thought to be an immediate release after Jakarta EE 8
to allow developers to start experimenting and understanding
the namespace change. That would be the intent of a
namespace-only Jakarta EE 9. Sure, it wouldn't provide
anything "interesting", but it would provide a release to
experiment with.
-----
Original message -----
From: "Steve Millidge (Payara)"
<steve.millidge@xxxxxxxxxxx>
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 11:20 AM
Hi Ivan,
Thanks you for
the perspective I think you are correct. The “legacy
profile” I think is a given as vendors of the runtimes
will obviously support customers running apps on the
javax.* namespace for many years. The current Payara
roadmap for example has Payara 5 supported out to 2028.
I’m sure Jakarta EE 8 when released on the old namespace
will be supported for many years. I think of it as a LTS
release.
I also think you
and Josh are also correct Jakarta EE 9 can’t just be a
namespace change as no organisation building
applications on Java EE 8 is going to take that hit for
nothing new and then as you say if there are new
concepts and apis introduced then the namespace change
will be small compared to modifying apps to take
advantage of the new Jakarta EE 9 features.
Steve
From:
jakartaee-platform-dev-bounces@xxxxxxxxxxx
<jakartaee-platform-dev-bounces@xxxxxxxxxxx> On
Behalf Of Ivan St. Ivanov
Sent: 07 May 2019 15:52
To: jakartaee-platform developer discussions
<jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev]
Transitioning Jakarta EE to the jakarta namespace
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.
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?
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.
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
_______________________________________________
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
|
