Jakarta EE 10 and Enterprise Beans: Options for the Future

With the release of Jakarta EE 9.1 in late May, attention is turning to Jakarta EE 10. Jakarta EE 10 will include a variety of new features as well as an overall realignment towards Contexts and Dependency Injection (CDI) technology. With this realignment, many developers are now wondering what will become of the former Enterprise Java Beans technology — now called Jakarta Enterprise Beans — that was so closely associated with the former J2EE platform?

Enterprise Beans Isn’t Advancing, But Must Be Supported

There are no immediate plans to advance the Jakarta Enterprise Beans specification, and there really isn’t much of a team around the technology at the moment. New versions of Jakarta Enterprise Beans are quite unlikely, and perhaps unwanted, given the platform’s goals.

Instead, the plan is for Jakarta EE 10 to introduce CDI-based versions of almost every Enterprise Bean feature. These features, along with Enterprise Beans features such as @Transactional, which already have alternatives, mean new code won’t need to use much, if any, of the Jakarta Enterprise Beans technology.

However, there is still a major use case to consider: Existing code that still uses a lot of Enterprise Beans, such as the @Stateless annotation. Older technologies, such as Eclipse GlassFish, will likely keep their venerable Enterprise Beans implementations around for a long time, and there is no plan to deprecate or prune the specification anytime soon.

Developers Have Multiple Approaches to Consider

Developers of new Jakarta runtimes, such as Piranha Cloud, have an interesting choice to make: Implement a Jakarta Enterprise Beans container from scratch, then pass the Jakarta EE compatibility certification process and function as a legacy option, or take a different approach.

Often, that different approach is simply packaging an existing implementation. For example, it’s very easy to add a Jakarta Server Faces implementation, such as Eclipse Mojarra. However, in the case of Enterprise Beans, this is not exactly trivial. Enterprise Bean implementations are often deeply embedded in the server, and have become the very heart of those servers. Some of the standalone implementations that once existed and that could be used on Eclipse Jetty, for example, were abandoned long ago, while other implementations, such as Apache OpenEJB, are challenging to integrate and have many dependencies.

Nearly a decade ago, David Blevins, the driving force behind the Jakarta EE 9.1 compatible server Apache TomEE, postulated in his influential article “CDI, when to break out the EJBs” that Enterprise Beans is not that different from CDI. A few years later, the OmniFaces team began implementing a few Enterprise Beans features as CDI extensions on top of CDI. These features were subsequently used in several projects instead of Enterprise Beans.

The developers of Piranha Cloud are now considering using this same approach to achieve Jakarta EE 10 compatibility certification: Implement Enterprise Beans as a set of extensions on top of CDI instead of having an Enterprise Beans container.

For full Enterprise Beans, this approach may not be feasible. Even though functionality such as Entity Beans, the 2.x API group, distributed interoperability, JAX-RPC endpoints, and views have all been pruned, some potentially troublesome aspects still remain. These aspects are primarily related to the ancient Common Object Request Broker Architecture (CORBA) technology. There are literally tens of thousands of tests in the Jakarta Enterprise Beans Technology Compatibility Kit (TCK) to confirm that every minute CORBA detail is implemented exactly as described in the Jakarta Enterprise Beans specification.

A “Lite” Approach to Enterprise Beans Has Benefits

However, there is also a simpler version of Jakarta Enterprise Beans that is aptly named Jakarta Enterprise Beans Lite. This is the version that Piranha Cloud will consider using to create a set of CDI-compatible extensions.

A key design requirement is to use only the public CDI APIs and Service Provider Interfaces (SPIs). With this approach, the Enterprise Beans extensions can be easily used with every CDI implementation — Weld, Apache OpenWebBeans, and the CDI-compatible HK2 dependency injection kernel that Payara Services is planning. This will help to ensure the Piranha Cloud code is maintainable. It will also help with the composability of Jakarta EE APIs and make them easily usable on technologies such as Apache Tomcat. These same design principles have been applied to the Jakarta Security compatible implementation, Eclipse Soteria, which means it can be used on Tomcat.

Another important aspect of this work is related to a CDI theme in Jakarta EE 10: Providing additional APIs and SPIs that help other Jakarta EE 10 APIs build on it. In the current Jakarta CDI specification (version 3.0), some key SPIs are still not standardized. One example is the ability to open up beans provided by a framework such as Jakarta Server Faces or Jakarta Security for decoration. At the moment, proprietary code must be called, which hinders the seamless composability referred to above, and puts a greater burden on implementations to keep such proprietary code working and up to date.

Join the Conversation

To get involved in Jakarta EE 10 discussions, subscribe to the mailing lists and join the Slack Workspace.

To help shape the future of open source, cloud native Java, join the Jakarta EE Working Group. New members are always welcome.