[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

Very good overview of the possible implementations for compatibility.

Questions which come to my mind:
- Is there a need to deploy applications to one application server instance using both APIs?
- Do we need an application server which is Java EE and Jakarta EE compatible at runtime?
- Is there a need to have an application server being Java EE and Jakarta EE backwards compatible for a long long time? Should this be specified or should vendors decide on their own?


Jens





Am 14.05.2019 um 09:58 schrieb Greg Wilkins <gregw@xxxxxxxxxxx>:

Binary compatibility sounds easy... Specially if it starts off as 1:1. But eventually APIs and behaviours will evolve so it will become 1:1.1 or more. Then binary compatibility is more difficult and nuanced.


And will contribute to the documents if it becomes worthwhile...

On Mon., 13 May 2019, 15:13 Peter P. Lupo, <pplupo@xxxxxxxxx> wrote:
If we have an 1:1 copy, we could provide a tool to migrate (i.e., replace the packages name).

Peter P. Lupo
Software Engineer, M.Sc.
Certified ScrumMaster / Sun Certified Associate for Java Platform
MPS.BR Authorized Appraiser and Implementation Practitioner
+1 647-676-3699
http://www.pplupo.com


On Mon, May 13, 2019 at 3:49 AM Jens KÃtterheinrich <jens@xxxxxxxxxxxxxxxx> wrote:

Hello everyone,


thank you for your work to get the community involved!

Hence here my thoughts about backwards compatibility of Jakarta EE:


In an enterprise environment there usually is more than one application running.

I think of different types:


1. Existing applications which should run as they are on an application server.

2. Existing applications which can be changed.

3. New applications.


If you have an application which cannot be changed (regardless of whether you do not own the code or you have no money for a change), you should stick with the existing application server. Usually if you do not have money for a change, you do not have money to test a change of the application server version. And if you do not own the code, there are usually requirements specified, which application server you should use.

I think of it as a matter of support by the vendors to support Java EE by their existing products as long as possible.


If you have an application, which can be changed, there should not be a problem to use jakarta.* instead of javax.*, if you have the same content.

Even though I would go with a clean up of the specifications (so having a different content in javax.* and jakarta.*), because Jakarta EE is about opening innovation for cloud and hence deserves a good foundation, I do not think that is a community wide point of view. Actually I think there is a desire for a migration as smooth as possible. Therefore the easiest migration path would be a 1:1 copy of the content from javax.* to jakarta.*. Then you could support migration by a tool, which changes the imports.


And the easiest part is a new application, where you can just use the new jakarta.*.


A problem might arise, when type 2 or 3 or both of them are mixed with type 1, because you have to run different application servers, if a vendor does not support Java EE in a new application server anymore. But that is actually an implementation detail. For example in Webshere you can use different runtime versions for each instance just by configuration; why not switch the specifications by configuration?


In short: Jakarta EE 9 should use jakarta.* with the content from javax.*.

And vendors can decide, whether they want to support both specifications in a transition time.


Jens


_______________________________________________
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