|[jakartaee-platform-dev] Oracle's position on Jakarta EE 9|
See attached for Oracle's proposal for Jakarta EE 9. We look forward to continuing this discussion.
# Oracle's proposal for Jakarta EE 9 The following is Oracle's proposal for what we should do for Jakarta EE 9. Nothing here is final, and we're open to discussion on all these items. Feedback is strongly encouraged. Counterproposals are welcomed. Our intent is to put a stake in the ground to start the planning for Jakarta EE 9. ## Pruning The following specifications should 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 Registries - Jakarta XML RPC - Jakarta Deployment - 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 should *not* be added to Jakarta EE 9. - Jakarta XML Web Services - Jakarta SOAP Attachments - Jakarta Web Service Metadata - CORBA and RMI-IIOP The following APs corresponding to Java SE 8 APIs *should* be added to Jakarta EE 9. - Jakarta XML Binding - Jakarta Activation ## Package Naming Oracle strongly supports 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 would be converted to the jakarta.* namespace. This would 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. Oracle does not have a strong position on whether such backwards compatibility support needs to be defined by a Jakarta EE specification. Oracle strongly encourages 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. Oracle does 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. Oracle believes this should be 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 Oracle is open to creating one or two additional Jakarta EE profiles to help additional vendors enter the Jakarta EE market. Oracle believes 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. Oracle believes that we should continue to evaluate whether all the APIs in the platform are still relevant to today's application, and consider making some of them optional and pruning them in later releases. ## Java SE Support and Modules Oracle believes Jakarta EE 9 should require at least Java SE 11. However, support for Java platform modules is much more complicated. Oracle supports defining some basic guidelines (e.g., naming) for specifications that choose to define modules. Oracle does not believe the entire Jakarta EE 9 platform needs to be defined based on modules. ## Microservices vs. Containers Oracle supports 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. ## Microprofile Oracle strongly believes 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. Oracle does not believe this needs to be done for Jakarta EE 9, and in general it should 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 Oracle supports 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 Oracle does 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.
Back to the top