Skip to main content

[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

Hi folks,

Thanks David for creating this discussion and laying out the options.

I've written down my views on the topic in a short blog post: https://blog.sebastian-daschner.com/entries/thoughts-on-jakarta-package-name

To make it easier for you, let me just copy its content here:



While this [change] is certainly bad news, for me, the bad news already started when it was announced that Jakarta EE can’t use the javax name for new specifications and sub-packages. That would have already mean continuing to evolve a platform that becomes more inconsistent over time.

Given the situation we’re in, I think it makes sense to make a clear cut and migrate to the proposed jakarta name.

This certainly means a huge impact for the whole Java ecosystem, everything that bases on any Enterprise API, not only the standards themselves. How to tackle that reasonably?

I believe the most important goal is to minimize the impact for the users, that is, developers out there. I see two major changes that have to be made, besides the code usage in projects.

Any runtimes that know and handle EE APIs, e.g. application servers, have to adapt and switch to the new name. They will have to implement some functionality to live with both javax and jakarta, very likely simultaneously, simply because they have to. There’s too much code out there that won’t be migrated to base on either javax or jakarta fashion. In the real world, there are legacy projects, tons of libraries and dependencies, binaries for which no source exists, and much more. We need a way to tell a runtime to just live with both, at least temporarily, or in specific compatibility profiles. There are already proposals how to do that, including Bytecode manipulation and other black magic :-) I’ve talked to IBM engineers that this is also the way Liberty will go. For me, making the life easier for developers has the highest importance.

The second big impact will be for frameworks, libraries, and tooling built around Enterprise Java that import something with javax contained in Java EE. At least once some new functionality is introduced, they will have to switch. If they want to ensure, that their project still works under Jakarta EE, even without a “compatibility runtime”, they’ll have to switch too. I think a clean cut is to offer the current Java EE APIs, under both Java EE, with javax, and Jakarta EE with jakarta. This would be needed for both the platform (javaee-api) and individual specifications such as JAX-RS. The projects then have an easy control, via their resolved dependencies, which one to use and can swap their imports accordingly. If Jakarta EE makes a clean cut, for example, switching only to the jakarta namespaces in the next release, say 9, or 8.1, but keeping everything else similar with Java EE 8, this makes it easier for projects to switch.

TL;DR

In my opinion, the Jakarta EE ecosystem should:

- minimize the impact for the users, that is developers
- make runtimes support both javax and jakarta, at least temporarily or in a compatibility profile
- make a clean cut to switch the package names in Jakarta EE platforms and individual standards, without switching any other functionality

- also, the world is not going to end (just yet) :-)



Sebastian

On Wed, May 8, 2019 at 7:18 AM Kazumura, Kenji <kzr@xxxxxxxxxxxxxx> wrote:

Richard,

 

I am not clear the motivation for application server vendors to provide “legacy profile”.

If they want to maintain binary and/or source compatibilities, they should just keep selling their Jakarta EE 8 products as long as possible.

What the advantage of “legacy profile” against to keep selling old products ?

 

-Kenji Kazumura

 

 

 

From: jakartaee-platform-dev-bounces@xxxxxxxxxxx [mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx] On Behalf Of Kevin Sutter
Sent: Tuesday, May 7, 2019 10:25 PM
To: jakartaee-platform-dev@xxxxxxxxxxx
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace

 

Richard,

I still like your idea of a "legacy profile".  I think this approach allows for existing application servers to maintain binary compatibility.  And, if it's an optional profile, then new application servers could start fresh with Jakarta EE 9 -- however that is defined.


---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter

 

 

----- Original message -----
From: Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx>
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 8:33 AM
 

Well, if I understand it correctly, the Incremental proposal moves only some of the javax specs to Jakarta EE, but takes place over the course of time (perhaps years) and allows developers to mix javax and jakarta namespaces. The Big bang moves everything over and doesn't require mixing of namespaces.  The Legacy effectively does a little of both. It makes the transition to Jakarta EE namespace all at once, but only some of the APIs are moved over and of those APIs only what is wanted/needed. Everything else is left behind forever. I think this does two things:  1) It makes it less likely that namespaces will be mixed. You either use Jakarta or Java EE; 2) It keeps the Jakarta namespace from being "polluted" by the javax namespace.  If we can review every API and copy over only what we want and add in what we want, we will effectively have a whole different platform. That may or may not be appealing, but its a fresh start for Jakarta.   

 

As an example, let say we decide we need a Jakarta Mail API, but there are a lot of things about Java Mail we don't' like, we could take inspiration from Java Mail but create an entirely new Jakarta Mail, perhaps one that separates the implementation from the API or addresses more modern requirements or can be used as a proper Resource in the Connector Architecture.   JMS may be another example. Perhaps we want a more general messaging framework which can be used for both inter- and intra-process messaging so Jakarta Messaging is very different from JMS and JMS is never supported in Jakarata EE.

 

In my opinion, Jakarta is a chance to take everything we've learned and start fresh with a green field.  The Legacy Profile allows us to continue to provide the javax namespace but in the Jakarta project as a legacy profile, which is both syntactically (different APIs) and semantically (different platform and branding) apart from Jakarta EE.

 

On Tue, May 7, 2019 at 7:04 AM Kevin Sutter <sutter@xxxxxxxxxx> wrote:

Richard,

I like your idea of a "legacy profile", which helps with the binary compatibility requirement.  But, I don't understand how it affects the decision of incremental vs big bang change for the namespace issue.  What am I missing?


---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter

 

 

----- Original message -----
From: Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx>
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 7:40 AM
 

I would like to propose a very different strategy from the incremental or big-bang as described in David B.'s email.

 

I think what would work best is what I call a "Legacy Profile" which is essentially everything that is Java EE 8 today.  The Legacy Profile would remain in the javax namespace and would never evolve beyond Java EE 8. With that in place, customers would know that sticking with the Legacy Profile means sticking with Java EE 8.

 

The jakarta namespace would be a fresh start.  We take a critical look at all that is Java EE and if we see something worth keeping we can copy some, or all of it, into the jakarta namespace. It would continue to exist frozen in the javax namespace in the Legacy Profile, but the Jakarta version would be clean of all unneeded APIs, packages, types, and depreciations and allowed to evolve as deemed necessary.  As an example, the JMS specification has three overlapping APIs in the javax namespace.   Those 3 APIs would always be accessible in the Legacy Profile, but moving forward all but one might be left out of the Jakarta Messaging Service API (or whatever its called). This is just an example of how we can move some, but not necessarily all, of an API to Jakarta while continuing to support compatibility with Java EE 8.  

 

Vendors could choose to support the Legacy Profile or not.  Customers who want to continue with the Java EE 8 would choose vendors who support the Legacy Profile.  Customers who want to move forward with Jakarta would choose vendors that support that platform.  A vendor could support both the Jakarta EE platform and the Legacy Profile if desired.  Whether or not applications could use both in the same package is another consideration with pros and cons. I don't have a firm opinion on the matter.

 

MicroProfile itself would remain a separate project with its own namespace, but a profile of the MicroProfile that Jakarta EE vendors can optionally adopt could be defined with some or all of the MP APIs. Again, although parts of MP are used as a Jakarta Profile the MP packages are not copied; they are used as is. This MP profile could evolve over time adding new APIs or dropping old ones, but because its a profile and not a required part of the Jakarta EE platform we show support for it while not requiring that the MP community move to Jakarta EE.

 

Through the use of profiles, we can keep Jakarta EE as a core while we make profiles expressing other domain-specific needs optional but still bound by branding and tests. So, for example, to support the Jakarta EE MP Profile v. 1.0 (or whatever) you would have to comply with the core Jakarta EE platform as well as TCKs and branding around the MicroProfile Profile.  Another different profile might be defined around Java Server Faces, or IoT or whatever is deemed necessary over time.

 

The Jakarta EE platform itself could evolve independently of the Profiles which themselves can evolve independently of each other - although versions of each profile would be specific to specified versions of Jakarta EE.

 

On Mon, May 6, 2019 at 6:23 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:

[Contents of this email represent discussions of the Jakarta EE Specification Committee over the last several meetings.  The statements here have been reviewed by and represent the voice of the Jakarta EE Specification Committee]

 

As announced in the Update on Jakarta EE Rights to Java Trademarks[1] post on Friday, future modification of the javax namespace will not be allowed.  While this is not what was envisioned when Jakarta EE started, in many ways this in our best interest as the modification of javax would always have involved long-term legal and trademark restrictions.

 

To evolve Jakarta EE, we must transition to a new namespace. The primary decisions we need to make as a community and industry are how and when. Given all delays and desires on everyone’s part to move forward as fast as possible, we would like to have this discussion openly as a community and conclude in one month. It is the hope that in one month a clear consensus emerges and can be presented to the Specification Committee for final approval.

 

In an effort to bootstrap the conversation, the Specification Committee has prepared two proposals for how we might move into the new namespace. These should be considered a starting point, more proposals are welcome. No final decisions have been made at this stage.

 

The guiding principle for Jakarta EE.next will be to maximize compatibility with Jakarta EE 8 for future versions without stifling innovation.

 

Other proposals should incorporate the following considerations and goals:

 

  • The new namespace will be jakarta.*
  • APIs moved to the jakarta namespace maintain class names and method signatures compatible with equivalent class names and method signatures in the javax.* namespace.
  • Even a small maintenance change to an API would require a javax to jakarta change of that entire specification. Examples include:
    • Adding a value to an enum
    • Overriding/adding a method signature
    • Adding default methods in interfaces
    • Compensating for Java language changes
  • Binary compatibility for existing applications in the javax namespace is an agreed goal by the majority of existing vendors in the Jakarta EE Working Group and would be a priority in their products. However, there is a strong desire not to deter new implementers of the jakarta namespace from entering the ecosystem by requiring they also implement an equivalent javax legacy API.
  • There is no intention to change Jakarta EE 8 goals or timeline.
  • Community discussion on how to transition to the jakarta namespace will conclude Sunday, June 9th, 2019.

 

It is envisioned binary compatibility can be achieved and offered by implementations via tooling that performs bytecode modification at either build-time, deploy-time or runtime. While there are open questions and considerations in this area, the primary goal of the discussion that must conclude is how do we move forward with future modifications to the APIs themselves.

Proposal 1: Big-bang Jakarta EE 9, Jakarta EE 10 New Features

The heart of this proposal is to do a one-time move of API source from the javax namespace to the jakarta namespace with the primary goal of not prolonging industry cost and pain associated with the transition.

 

Were we to take this path, a compelling approach would be to do the namespace rename and immediately release this as Jakarta EE 9. Additional modifications would be put into a Jakarta EE 10 which can be developed in parallel, without further delays.

 

  • Some or all Jakarta EE APIs under javax would move immediately into jakarta as-is.
  • Any packages not moved from javax to jakarta could be included in Jakarta EE, but would be forever frozen and never move to the jakarta namespace.
  • Jakarta EE 9 would be refocused as quick, stepping-stone release, identical to Jakarta EE 8 with the exception of the javax to jakarta namespace change and immediately released.
  • Jakarta EE 10 would become the new release name for what we imagined as Jakarta EE.next with only minor impact on timeline.
  • Work on Jakarta EE 10 could start immediately after rename is completed in the GitHub source and need not wait for the Jakarta EE 9 release to actually ship.

Pros:

  • One-time coordination and cost to the industry, including; conversion tools, users, enterprises, cloud vendors, IDE creators, platform vendors, trainers and book authors.
  • Easily understood rule: everything Jakarta EE 8 and before is javax, Jakarta EE 9 and after is jakarta
  • Consistent with the javax to jakarta Maven groupId change.
  • Highest degree of flexibility and freedom of action, post-change.
  • Industry would have the opportunity to begin digesting the namespace change far in advance of any major new APIs or feature changes.

Cons:

  • Largest upfront cost for everyone.
  • Specifications that may never be updated would still likely be moved.
  • Decision to not move a specification is permanent and therefore requires high confidence.

Decisions:

  • Which specifications, if any, would we opt not to move?
  • Would we take the opportunity to prune specifications from Jakarta EE 9?
  • Do we change the language level in Jakarta EE 9 to Java SE 11 or delay that to Jakarta EE 10?

 

Proposal 2: Incremental Change in Jakarta EE 9 and beyond

Evolve API source from javax to the jakarta namespace over time on an as-needed basis.  The most active specifications would immediately move in Jakarta EE 9.  Every Jakarta EE release, starting with version 10 and beyond may involve some javax to jakarta namespace transition.

 

  • The most active APIs would immediately move from javax to jakarta
  • APIs not changed or determined by the community to be unlikely to change would stay in javax
  • Jakarta EE 9 would be a mix of javax and jakarta packaged APIs
  • If a change was needed to a javax API post Jakarta EE 9 for any reason, that API would transition from javax to jakarta.
  • Jakarta EE 10 would be a mix of javax and jakarta packaged APIs, but a different mix than Jakarta EE 9.
  • At some point down the road, Jakarta EE xx, it may be decided that the migration from javax to jakarta is “done” and the final APIs are moved.

Pros:

  • Cheaper up front cost and reduced immediate noise.
  • No need to move specifications unless there is an immediately visible benefit.
  • Potential for less impact from API change overall.

Cons:

  • Prolonged coordination, cost and complexity to industry affecting conversion tools, users, enterprises, cloud vendors, IDE creators, platform vendors, trainers and book authors.
  • Use of restricted javax namespace prolonged.
  • Frustration of “always changing” packages may deter application developers and become a permanent perception of the brand.
  • Difficulty in remembering/knowing which Jakarta EE release an API was moved. “Is Connector javax or jakarta in Jakarta EE 11?”
  • Difficulty in keeping the industry in sync.
  • New implementations may find themselves having to deal with the javax to jakarta transition, unable to avoid legacy costs and therefore decide not to enter the space.
  • Transitive dependencies to other specifications may make incremental change difficult or impossible.
  • Restrictions on what Java SE implementation can be used for certification

Decisions:

  • Do we start small or start large?
  • Which APIs would immediately need to be changed?

Out of Scope

The following are very important community discussions, but do not require a decision in the time-frame allotted:

 

  • Roadmap or release date for any Jakarta EE.next that would contain new features
  • List of specifications that may be deprecated, pruned or removed from Jakarta EE.next, if any
  • Specification text around backwards compatibility requirements, if any
  • What profiles should be defined

 

However, depending on the path chosen, some of these topics may require immediate resolution before the chosen path can be executed.

 

 

 

_______________________________________________
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

 

 

--

_______________________________________________
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

Back to the top