Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
31 lines (22 sloc) 2.24 KB

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?

You can’t perform that action at this time.