[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

Reading this last email comes to my mind that is maybe will be good call the package jakartax.* from the user perspective can be easy to be familiarize with the naming change I don't know what do you think folks?Â

Cheers

On Wed, May 8, 2019, 00:28 Scott Stark <starksm64@xxxxxxxxx> wrote:
This is essentially proposal 2 with a stated compatibility requirement. While the requirement for compatibility is being discussed, the spec committee wanted to separate out that discussion from initial feedback targeted toward just what type of move away from javax people wanted. Certainly compatibility requirements dovetail into this discussion, but depending on how it is implemented, it can be orthogonal.

For example, our servlet spec lead suggested that they could create a compatibility library that mapped the legacy javax.servlet classes onto the current jakarta.servlet APIs, and the container could do whatever wiring was needed to fill in the gaps.

Similarly there have been discussions of a variation of the maven shade plugin that mapped the legacy javax classes and resources onto the new versions so that the container implementations are only dealing with the new APIs.


On Tue, May 7, 2019 at 2:57 PM Nathan Rauh <nathan.rauh@xxxxxxxxxx> wrote:
I'll start by pointing out that these are some of my own thoughts and do not represent any position on the part of my employer.

One of the really valuable parts of Java EE as a standard is the wide array of pluggable third party implementations that are available. I worry that if we put out a breaking spec change like package renames (you can't implement both interface variants under a single implementation class due to details like spec-defined concrete exception classes), that a number of third-party implementations will simply never update to jakarta, and applications will be torn between their dependencies vs taking advantage of improvements in other specs at newer levels. Many applications will stay behind as well, make attempts to mix different jakarta.* and javax.* technologies, or move away from Java altogether. Some providers/applications/vendors which have a desire to support both javax and jakarta will overcome the breaking changes, but will do so at the cost of increased footprint.

There is another option that should at least be considered. What if we just keep the javax packages as they are and leave them alone, still fully part of Jakarta with each subsequent release? Full compatibility would be maintained. ÂEnhancements could instead be made by parallel specs that introduce individual interfaces under jakarta.*, but only as needed. Completely new specs would of course be written under jakarta.*. Sure, there is some inconvenience here (extra imports for users, maybe a need for creative interface design in places, probably some unwanted limitations on changes that can be made). However, that may be a small price to pay to avoid all of the churn, confusion and trouble that would otherwise arise from having duplicate implementations per package name, existing probably indefinitely for as many of the third-party providers of resource adapters, JMS providers, JPA providers, JSON-P/B providers... and so on, as are willing to provide a jakarta.* variant.



_______________________________________________
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