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

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

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.