Guide to Contributing to Jakarta EE 10

Ways of Contributing

There are many ways of contributing to Jakarta EE 10, depending on what your time and interest allow. You can always start simple and get more engaged over time.

  • 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 10 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 you would like to advocate for, you should do so on the mailing list to start with. 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 should be able to find the issue tracker for projects from here. We specifically link the issue trackers for some likely key Jakarta EE 10 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 an API change, a TCK change or a change in 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 any code.

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 will be able to just complete it as an individual without any signatures from your employer. You don’t need to pay anything either. 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 and 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 10 Contents

There is not yet a formal roadmap for Jakarta EE 10 but you should not wait for one to begin contributing. The expectation so far is that Jakarta EE 10 will be delivered some time in 2021. As the Jakarta EE 9.1 work has wrapped up, there is no reason work on Jakarta EE 10 should not begin.

Ultimately it is up to each technology project what changes are implemented and you can help influence that yourself. You should begin engaging whichever technologies and features interest you the most. It is likely only a subset of technologies will change for Jakarta EE 10. 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 more or less well-vetted key ideas in the Jakarta EE Ambassadors community (most of these ideas are relatively long-standing and well understood). 

The envisioned changes more or less appear to follow these general themes so far:

  • Aligning specifications and features to take better advantage of CDI, making CDI truly the central component model for Jakarta EE. This includes deprecating EJB as a technology in favor of equivalent, modernized, more flexible CDI-centric functionality.
  • 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.
  • Achieving greater portability and vendor-neutrality by including more commonly used features that are vendor-specific today or available outside Jakarta EE technologies. Many of these features represent long-standing feature gaps.

Platform Level Changes

Below are possible Jakarta EE platform-level changes. While it is best 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 5/Arquillian. While a lot of work has also been done in Jakarta EE 9 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 deprecate 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, OSGi, and JBoss Modules. The first steps will probably be modest such as adding automatic-module-name in MANIFEST.MF and providing a correct module-info.java.
  • Introduce a Core/Microservices Profile (initially consisting of updated CDI, REST, JSON)? The basic idea is to have a new, small profile that could be the foundation for MicroProfile and Jakarta EE runtimes, possibly including aligning some key existing MicroProfile APIs with Jakarta EE 10. The profile likely entails creating a lighter version of CDI that includes a subset of features targeting Jakarta EE but a superset of features targeting CDI Core/Java SE.

Security

Jakarta Security already brought an important set of changes in Jakarta EE 8. 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.

  1. Adding support for OAuth2, JWT and OpenID Connect.
  2. Providing CDI-friendly, modernized equivalents for @RolesAllowed and @RunAs.
  3. Adding an EL-enabled authorization annotation in addition to @RolesAllowed (e.g. @Authorized(“callerPrincipal.name == ‘Arjan’”)).
  4. 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 its initial release, Jakarta Concurrency introduced a number of long-pending changes to improve portability 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 @Asynchronous, @Schedule, and @Lock.
  • Adding a @MaxConcurrency annotation.
  • Adding a @ManagedExecutorServiceDefinition annotation for more portably defining managed executors.
  • Adding support for Java SE completable futures in a managed fashion.
  • Properly propagating the CDI context across managed threads.

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 discussed extensively in the EJB and JMS projects but not implemented due to time 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. You may need to enter issues for these changes.

  • Provide CDI-friendly equivalents for MDB.
  • Provide a Java SE/standalone bootstrap API.
  • Include JMS-AMQP interoperability?
  • Include JMS-Kafka interoperability?
  • Include JMS-MQTT 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. You may need to enter issues for these changes.

  • 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?
  • A repository abstraction over Jakarta Persistence similar to DeltaSpike Data?
  • Support multi-tenancy?

REST

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 these have already been discussed in the JAX-RS/Jakarta REST project). The best place to start discussing these changes is the Jakarta REST mailing list.

  • Using CDI/@Inject instead of @Context injection.
  • Provide a Java SE/standalone bootstrap API.
  • Add native support for multipart/form-data.

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.

Mail

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 modelling 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.

Transactions

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 optimizations that are relatively commonplace 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.

Faces

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

  • Enable REST-friendly, extension-less URL access.
  • Remove deprecated APIs including JSF managed beans.
  • Remove support for JSP as a Faces view technology (JSP would remain an overall part of Jakarta EE).

New APIs

Aside from changes to existing APIs, a few new APIs could be added as part of the Jakarta EE umbrella.

  • Jakarta NoSQL aims to enable NoSQL access for Jakarta EE applications. The best way to get involved is to explore the project, including joining the mailing list.
  • Jakarta MVC aims to provide a more action-oriented Java web framework for Jakarta EE applications. The best way to get involved is to explore the project, including joining the mailing list.
  • Adding the ability to externalize configuration 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, Messaging, and Mail. It is possible this need could be met through MicroProfile alignment. Currently, the best place to discuss this change is the Jakarta EE specification 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 10

There are a few further changes on the horizon that are likely too early for Jakarta EE 10. 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.
  • More reactive/NIO capabilities in the Servlet or equivalent layer.
  • Better reactive/NIO support in APIs such as Persistence (requires a widely supported version of reactive/NIO JDBC first, ideally in Java SE), REST, MVC and Messaging.
  • Moving Arquillian to the Eclipse Foundation and make it part of EE4J? Another possible approach is aligning/integrating with testing initiatives like MicroShed and TestContainers.