[jakartaee-platform-dev] Oracle's position on Jakarta EE 9

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

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.