Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Jakarta EE 9 proposed plan

Copying over the post I made last night on the Red Hat position on the suggested approach for EE 9.

- Pruning
Red Hat mostly agree with the API pruning, but there are some questions around SOAP that need to be discussed further.

- Package Naming / Backwards Compatibility
Red Hat mostly agree with renaming all packages to the jakarta.* namespace. The wildcard here is that even though we agree that backward compatibility should not be a spec mandate, we do support the common open source backward compatibility project idea and can envision that a feedback loop could develop that changes the opinion on how to best achieve this.

- API Compatibility
Red Hat believe that there should be no incompatible changes beyond the package naming change.

- Enhancements
Red Hat believe there should be no enhancements as there is plenty to do with just the package renaming and any other changes will certainly push out an EE 9 release date.

- Profiles
Red Hat believe that additional profiles are needed to allow for adapting certifiable containers to much smaller subsets than are supported in EE 8. Red Hat also believe that relying on JPMS is not the way to do this.

- Java SE Support and Modules
Red Hat believe that Java SE 11 should be the baseline for EE 9 and also agree that JPMS requirements are not something EE 9 should be attempting to address.

- Microservices vs Containers
Red Hat believe that Java SE support should be expanded to as many APIs as make sense to support the lighter weight microservice oriented run-times we envision as being important in the future.

Getting TCK runs completed was a significant challenge due to the current configuration of permissions in the Eclipse CI environment during the EE 8 release. While it does make sense to split the TCKs up into project aligned with the specification project, doing so for EE 9 would be a major task that would push the EE 9 release date significantly. There should be some investigation into providing read and run access to the jakartaee-tck project CI jobs to facilitate testing of API release candidates without needing to significantly refactor the platform TCK projects.

On Wed, Oct 9, 2019 at 5:00 PM Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
Thanks for all the input on, and support of, Oracle's proposed plan for
Jakarta EE 9.  Given the widespread overall support, I've recast this as
the proposed plan from the Jakarta EE platform project.  After further
review and feedback, I'll ask the platform committers to vote on this

I made the following significant changes to the plan:

- pruned Jakarta Management
- backwards compatibility NOT included
- no new profiles
- Microprofile APIs NOT included
- release in 12 months or less

Some of the changes above were motivated by the desire to release sooner
rather than later, which seemed to be the consensus.

The most feedback was probably around the removal of SOAP support.
I think we've adequately explained that products can continue to
provide SOAP support based on the Jakarta versions of the corresponding
specifications, which will have no changes to their APIs and will
continue to use the javax namespace.  If platform project committers
believe SOAP support MUST be included, now is the time to speak up.
Note that this would have a significant impact on the amount of work
to be done for Jakarta EE 9.

Every detail in the plan will have someone who objects.  What I'm trying
to achieve is consensus on a plan that most people can support, even if
no one thinks it's perfect.  As usual, I'm looking forward to your
continued feedback, especially if you think I'm moving in the wrong direction.

jakartaee-platform-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top