|Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace|
This is not true. The big bang allows to extend the existing packages once they are renamed. This means, once an application is migrated, now *new* packages are needed to be imported at a later time.
Not really. My point is no different from Big Bang or incremental approach when it comes to consume new updates. All of the approaches require importing new packages.
On May 18, 2019 at 5:27 pm, <Markus KARG> wrote:
Your idea would cut off all existing apps from easily adopting minor enhancements of existing APIs and would enforce to migrate to completely new APIs, which is more work and higher risk than simply once change the imported package names. Typically existing apps are not maintained just to get free of bugs but also to adopt these small enhancements, and nobody wants to rewrite his app from Jakarta API to Microprofile API just to have one new parameter in a method.
We discussed Big Bang and incremental approach so far. Both of them have pros and cons. How about we do something in between:
Directly lock javax JSRs. For any new update related to a particular JSR, just start the new changes under Jakarta EE namespace without changing the existing APIs. For an example, MicroProfile Rest Client is an update to Rest client. MicroProfile context propagation is an update on Concurrence JSR. In MicroProfile, we create new APIs without changing any Java EE specs. We can use this approach for Jakarta EE spec updates. The only difference is to use jakata.ee namespace. In this way, we can directly create any APIs.
I think changing the current javax either Big Bang or incrementally will impact existing users. As you may know, some old libs may not have the source available any more. I think what I recommend does not impact any existing apps.
On May 18, 2019 at 3:10 pm, <Peter P. Lupo> wrote:
All the points made in favor of the big bang so far are pretty relevant and good points. I also agree with the big bang. I like the idea of providing an alternative to the existing API so we can provide a tool to migrate the existing applications but I would only go this far in terms of keeping existing functionality.
Truth being told, Java EE needs pruning. The more features we add, greater is the effort to keep backward compatibility, making enhancements costly.
We could provide a Jakarta.legacy package for equivalence and start fresh under Jakarta.*, keeping what is useful, adding new stuff and removing stuff like ejb older than 3.1, etc...
On Sat, May 18, 2019, 09:49 Josh Juneau <juneau001@xxxxxxxxx> wrote:
_______________________________________________ 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
Back to the top