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.
- TCK
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.
