[jakartaee-platform-dev] Jakarta EE 9 proposed plan

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 plan. 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. Thanks.

# Jakarta EE 9 Proposed Plan The following is the proposed plan from the Jakarta EE platform project for Jakarta EE 9. ## Pruning The following specifications will be *removed* from Jakarta EE 9. These projects would continue to exist at Eclipse, but we would expect no further updates to the specifications. The implementation projects may produce service releases as required to support existing customers. Jakarta EE 9 products may include support for these specifications even though such support would not be defined by the Jakarta EE 9 platform specification. - Jakarta XML Registries - Jakarta XML RPC - Jakarta Deployment - Jakarta Management - Jakarta Enterprise Bean entity beans - Jakarta Enterprise Bean interoperability - Jakarta Enterprise Bean 2.x and 1.x client view - Jakarta Enterprise Web Services The following APIs corresponding to Java SE 8 APIs will *not* be added to Jakarta EE 9. - Jakarta XML Web Services - Jakarta SOAP Attachments - Jakarta Web Service Metadata - CORBA and RMI-IIOP The following APIs corresponding to Java SE 8 APIs *will* be added to Jakarta EE 9. - Jakarta XML Binding - Jakarta Activation ## Package Naming We choose the "big bang" approach to switching to the new jakarta.* Java package names. After removing the specifications above from the platform, all specifications remaining in the platform will be converted to the jakarta.* namespace. This will result in new major versions of the corresponding specifications. ## Backwards Compatibility It's clear that nearly all existing Java EE and Jakarta EE products will need to provide some sort of backwards compatibility to allow existing applications to work unchanged on Jakarta EE 9 products using the new jakarta.* namespace. Such backwards compatibility support wil *not* be defined by a Jakarta EE specification. We strongly encourage the creation of an open source project to produce backwards compatibility support that can be shared by multiple implementations of Jakarta EE 9. ## API Compatibility One approach to providing backwards compatibility is to simply map all uses of Jakarta EE 8 javax.* packages to identically named jakarta.* packages. We do not believe this mapping needs to be an "identity" mapping. Simplification of the package naming structure can be considered as part of this mapping. If only package names are mapped, the success of backwards compatibility depends on all the same classes with the same names and same semantics continuing to exist in Jakarta EE 9. This is a very strong goal, but not an absolute requirement. There may be cases where (for example) APIs have been deprecated previously and could be removed in Jakarta EE 9. But in general, significant incompatible changes should not be made. ## Enhancements Upwards compatible enhancements to APIs can be considered provided that such work does not significantly delay the Jakarta EE 9 release. Some projects are already considering such enhancements, and this work is encouraged, within the constraints described here. ## Profiles and Optional APIs We are open to creating one or two additional Jakarta EE profiles to help additional vendors enter the Jakarta EE market, although at this point no additional profiles are being proposed for Jakarta EE 9. We believe that the need of developers to "right-size" their application deployment is best addressed by the use of Java platform modules, not profiles, defined by a future Jakarta EE release. We will continue to evaluate whether all the APIs in the platform are still relevant to today's applications, and consider making some of them optional and pruning them in later releases. At this point, no additional optional or pruned APIs beyond those listed above are being proposed for Jakarta EE 9. ## Java SE Support and Modules Jakarta EE 9 requires at least Java SE 11. However, support for Java platform modules is much more complicated. We will define some basic guidelines (e.g., naming) for specifications that choose to define modules. However, the entire Jakarta EE 9 platform will not be defined based on modules. ## Microservices vs. Containers We support the continued evolution of the Jakarta EE platform to support microservices, including the addition of non-container (standalone Java SE) support to more of the Jakarta EE APIs. Such enhancements should be considered as described above. ## Microprofile We strongly believe that all Microprofile work should be done under the Eclipse Foundation Specification Process, and should be considered as additions to the Jakarta EE platform under the Jakarta EE Specification Process. We do not expect this work will be done for Jakarta EE 9; it will be deferred to a future Jakarta EE release. When and how Microprofile APIs should be added to the Jakarta EE platform is an open issue. ## TCK We support the desire of the community to split up the Jakarta EE TCK project so that each specification project can manage its own TCK. However, this is a significant amount of work and we do not believe this work needs to be done for Jakarta EE 9. Possibly incremental progress can be made in the Jakarta EE 9 timeframe. It's essential that work in this area not make it more difficult to test a Jakarta EE 9 product. ## Release Time Frame We recommend that Jakarta EE 9 be delivered 12 months or less after Jakarta EE 8.