Guide to Contributing to Jakarta EE 11

Ways of Contributing

There are many ways of contributing to Jakarta EE 11, depending on what your time and interests allow. You can always start simple and get more engaged over time if you want.

You can simply follow a Jakarta EE technology that interests you. The easiest way to do that is by subscribing to its mailing list. All the Jakarta mailing lists are available here. We specifically link the mailing lists for some likely key Jakarta EE 11 technologies below. You should feel free to join discussions that interest you. Contributing your opinion as an end-user is one of the most valuable things you can do.
If you have a specific feature for which you’d like to advocate, the best way is to start with the mailing list. It may be necessary to record an issue detailing the feature if it does not already exist. Each project has a GitHub repository where you can record issues. You can find the issue tracker for projects here. We specifically link the issue trackers for some likely key Jakarta EE 11 technologies below.
If you want to help implement a change in the technology, you should look through the issue trackers and ask to pick up an issue on the mailing list. You can contribute changes to an API, a Technology Compatibility Kit (TCK), documentation, or one of the technology implementations (such as GlassFish, Jersey, Mojarra, OpenMQ or EclipseLink). Providing a proof-of-concept, if you can, is a great way to advocate for change (although this is clearly not an expectation from everyone).
If you are unsure where to start, just get on a mailing list, introduce yourself and say you want to help. There should be a Jakarta EE Ambassador present to engage you. You can also reach out through the Jakarta EE Ambassadors Google Group.

Eclipse Foundation Paperwork

There is no need to fill out any paperwork just to follow a project, record issues, and participate in discussions. You will only need paperwork for anything beyond that like contributing code or documentation.

When you are ready to take that next step, please make sure to sign the Eclipse Contributor Agreement (ECA). All you need in order to be a code contributor is to sign the ECA, that’s it. You can just complete it as an individual without any signatures from your employer. You don’t need to pay anything. You may need some paperwork from your employer if you want to be a committer instead of a contributor. Being a committer typically comes much later. It’s something you don’t need to worry about right away.

If you have any questions about this, please let us know. For further reference, feel free to read this blog post by Wayne Beaton, director of open source projects at the Eclipse Foundation. Most of it is focused on the process of becoming a committer. There is also a FAQ on the ECA.

Jakarta EE 11 Contents

There is not yet a formal roadmap for Jakarta EE 11, but you don’t have to wait for one to begin contributing. The expectation so far is that Jakarta EE 11 will be delivered some time in 2024. You can begin work to move forward Jakarta EE 11 right now.

Ultimately each project decides which changes are implemented, and you can help influence that yourself. You should begin engaging with whichever technologies and features interest you the most. It is likely only a subset of technologies will change for Jakarta EE 11. Below are some key changes we feel pretty confident about (slightly more uncertain changes have question marks). By no means should you treat these as a sure thing or the only sensible changes. These are relatively well-vetted key ideas in the Jakarta EE Ambassadors community (most of these ideas are relatively long-standing and well understood).

So far, the envisioned changes more or less follow these general themes:

Aligning specifications and features to take better advantage of Contexts and Dependency Injection (CDI), making CDI truly the central component model for Jakarta EE. This includes providing similar capabilities to EJB as a technology in favor of equivalent, modernized, more flexible CDI-centric functionality.
Achieving greater portability and vendor-neutrality by standardizing more commonly used features and technologies that are vendor-specific today or available outside Jakarta EE. Some of these represent long-standing feature gaps in existing specifications. Some entail adding new specifications for areas such as configuration, NoSQL and gRPC.
Aligning specifications and features to take better advantage of Java SE innovations. This includes making more technologies usable standalone, outside of a Jakarta EE platform implementation and having more standalone TCKs. It is likely the Java SE version supported by the platform will be upgraded to Java SE 17 or higher.

Platform Level Changes

Below are possible Jakarta EE platform-level changes. While it is best that the changes are agreed upon at the platform level, it is possible to go ahead with the work with each Jakarta EE technology. There are several mailing lists where platform-level changes can be discussed, but the best one to start with is likely the Jakarta EE specification mailing list. There is a separate mailing list for TCK discussions.

Modernize TCKs to utilize JUnit better. While a lot of work has also been done in Jakarta EE 10 to have completely separated TCKs, there is more work to be done. In a similar vein, there is work left to adopt Maven as the build system across all Jakarta projects.
Introduce a @Service CDI stereotype that seeks to provide similar capabilities to EJB @Stateless.
Create more custom websites for Jakarta EE technologies (e.g. https://beanvalidation.org, http://www.cdi-spec.org).
Help clean up and prioritize issues.
Improving modularity support in the platform. The basic idea is to adopt modularity, perhaps utilizing established technologies such as the Java Platform Module System and OSGi. The first steps will probably be modest such as adding automatic-module-name in MANIFEST.MF and providing a correct module-info.java.

Security

Jakarta Security already brought an important set of changes in Jakarta EE 10. However, there were a number of important pending changes that could not be implemented because of time. Security is also an important vehicle for providing CDI-friendly equivalents of EJB functionality. The best place to start discussing these changes is the Jakarta Security mailing list.

Addressing JWT/OAuth support (especially for use with OpenID Connect), including handling multiple authentication/authorization mechanisms in the same application.
Providing CDI-friendly, modernized equivalents for @RolesAllowed and @RunAs.
Adding an EL-enabled authorization annotation in addition to @RolesAllowed (e.g. @Authorized(“callerPrincipal.name == ‘Arjan’”)).
Providing a simple embedded identity store for testing and development purposes? The following is an API example that has been discussed previously:

@EmbeddedIdentityStoreDefinition({
    @Credentials(
	callerName = "caller1", 
	password = "secret1", 
	groups = { "VIEW_USER_PAGES", "VIEW_ADMIN_PAGES" }),
    @Credentials(
	callerName = "caller2", 
	password = "secret2", 
	groups = { "VIEW_USER_PAGES" })
)

Concurrency

In Jakarta EE 10, Jakarta Concurrency introduced a number of long-pending changes to improve portability, usability and vendor neutrality. Largely due to timing, a few important changes were missed. Concurrency is also an important vehicle for providing CDI-friendly equivalents for functionality available only in EJB, often supplied in vendor-specific ways. Many of these changes have been already discussed in the EJB, CDI, or MicroProfile projects. The best place to start discussing these changes is the Jakarta Concurrency mailing list.

Adding CDI-friendly equivalents for @Schedule and @Lock.
Adding a @MaxConcurrency annotation.

Messaging

Jakarta Messaging is an important vehicle for providing CDI-friendly equivalents for functionality currently available only through EJB Message Driven Beans (MDB). These are changes that have been extensively discussed in the EJB and JMS projects, but not implemented due to resource constraints. There are also other features that may help make Jakarta Messaging more compelling to a broader set of developers. The best place to start discussing these changes is the Jakarta Messaging mailing list.

Provide CDI-friendly equivalents for MDB.
Provide a Java SE/standalone bootstrap API.
Introducing JMS Lite geared towards cloud native use cases?
Include JMS-AMQP interoperability?

Persistence

Jakarta Persistence is a relatively mature and feature-complete technology. However, there are a few long-standing gaps that are likely important to address for end users. The best place to start discussing these changes is the Jakarta Persistence mailing list.

Alignment with Java SE Records.
Make persistence.xml optional/an empty marker in Jakarta EE applications.
Add more SQL features to JPQL and the Criteria API such as sub-selects?
Support JCache as a second-level cache provider?

REST

Jakarta RESTful Web Services, AKA Jakarta REST, is a relatively mature and feature-complete technology. However, there are a few long-standing gaps that are likely important to address (most of this has already been discussed in the JAX-RS/Jakarta REST project). The best place to start discussing the changes is the Jakarta REST mailing list.

Using CDI/@Inject instead of @Context injection.

Batch

Jakarta Batch is a relatively mature and feature-complete technology. However, there are a few likely changes that have already been mentioned in the Batch project. The best place to start discussing these changes is the Jakarta Batch mailing list.

Aligning Jakarta Batch to take better advantage of CDI/injection.
Add a Java job definition API as an alternative to XML.

MVC

Jakarta MVC is a relatively new specification that aims to provide a more action-oriented Java web framework for Jakarta EE applications. It could be added to Jakarta EE profiles or remain standalone. The best way to get involved is to explore the project, including joining the mailing list.

NoSQL

Jakarta NoSQL is a relatively new specification that aims to enable NoSQL access for Jakarta EE applications. It could be added to Jakarta EE profiles or remain standalone. The best way to get involved is to explore the project, including joining the mailing list.

Config

Jakarta Config is a new specification that aims to address the ability to externalize configuration. This has been a long-standing gap discussed since Java EE 7. A key goal is that specifications that need significant configuration can consume it from outside the application such as the environment. Some example specifications that could use this functionality include Persistence, NoSQL, Messaging, and Mail. The best way to get involved is to explore the project, including joining the mailing list.

Data

Jakarta Data is a new specification that aims to provide a higher level data access abstraction similar to Spring Data or DeltaSpike Data. It encompasses both Jakarta Persistence (JPA) and Jakarta NoSQL. The best way to get involved is to explore the project, including joining the mailing list.

RPC

Jakarta RPC is a new specification that aims to bring gRPC support to the platform. The concept is very similar to Jakarta REST. It could be added to Jakarta EE profiles or remain standalone. The best way to get involved is to explore the project, including joining the mailing list.

Non-Specification Projects

Aside from Jakarta EE specifications, there are a few closely related projects that you could contribute to. The best way to get involved is by exploring the projects and volunteering to help on their mailing lists. These projects are typically less technically involved than Jakarta EE specifications.

Post Jakarta EE 11

There are a few further changes on the horizon that are likely too early for Jakarta EE 11. Many of these features could use further maturing, analysis, development, and experimentation – perhaps outside Jakarta EE first. You should feel free to engage the broader community in discussion around these changes.

JSON schema support in JSON Processing and JSON Binding.
Addressing testing in a generic, holistic fashion for Jakarta EE applications. This work could be a specification or simply an EE4J umbrella project. Arquillian, MicroShed, TestContainers, and JUnit 5 are all possible technologies to leverage or get inspiration from.
Jakarta Mail is a relatively mature and feature-complete technology. There is, however, possibly an important usability gap to address: adding a higher-level CDI-based API that would provide a better abstraction for modeling common, non-trivial use cases such as sending a complex email with HTML or attachments. This is similar to the JMSContext API included in Jakarta Messaging. The likely best approach to this change is implementing an experimental open-source CDI extension within a project like Apache DeltaSpike.
Jakarta Transactions is a mature API that remains the sensible choice for managed transactions in Jakarta EE applications. However, an important gap that could be filled is further vendor-specific optimizations that are pretty common such as last resource commit optimization/one-phase commit/local transactions (e.g. WebLogic specific features that could be requested to be contributed by the vendor to the specification as basis for further improvement). The best place to start discussing these changes is the Jakarta Transactions mailing list.