Jakarta EE: What's in store for Enterprise JavaBeans?

Enterprise JavaBeans (EJB) has been very important to the Java EE ecosystem and promoted many robust solutions to enterprise problems. Besides that, in the past when integration techniques were not so advanced, EJB did great work with remote EJB, integrating many Java EE applications. However, remote EJB is not necessary anymore, and we have many techniques and tools that are better for doing that. So, does EJB still have a place in this new cloud-native world?

Before writing this post, I did an informal survey via Twitter poll to hear what the community thinks about it. In this article, I'll share the results of the survey as well as some discussion that emerged as part of the poll. Additionally, I'll share my opinions on the topic.

Twitter survey

Here is the question I asked in the survey along with the results (from 385 respondents):

We had many changes in the Java ecosystem mainly in Java enterprise. But what do you think about the EJB future? Do you think EJB has its place in this new cloud-native world? 

1. Yes, but needs updates .....29%
2. No, EJB is unnecessary ....50%
3. Yes, it's very useful ............17%
4. Other ...................................4%

As you can see, option 2 is the winner, and the majority of respondents think EJB is unnecessary. However, it's the winner with 50% of the vote, which means that 50% of respondents think EJB is necessary in some way or have some other opinion. That's not the only interesting thing in this survey, though; the other interesting thing was the discussion emerged from this survey about getting the interesting features from EJB and distributing them to other specs with more affinity. But before we get into this discussion, I'll share my opinion and explain why I think this.

My vote

My vote is for option 1 (Yes, but needs updates), because although EJB is an old technology, it has many features that are useful to the enterprise environment. But EJB can be sanitized to offer these features in a lighter technology. Here's a list of EJB's interesting features:

• Asynchronous invocation: Is useful when you want to make a non-blocking call to some method.
• Stateless EJBs pool: Optimizes memory use, promoting reuse of stateless EJB objects.
• @Startup to call a method at startup time: Is useful when we want to execute something at startup time.
• EJB timer: Is a good feature to schedule a process to execute according to some configuration.
• Singleton: Is useful when we want only one instance of an object to all applications. Furthermore, it has the method lock feature that is useful when we need to control concurrent access to some method.
• Message-driven bean (MDB): Is very useful to consume JMS queues and topics. It promotes a simple interface with a high level of abstraction to consume JMS.
• Transaction management: Is useful to manage transactions with databases and resources (like JMS). It promotes a high level of abstraction to work with transnational processes.

These features are useful to the current scenario of the enterprise world, and having these features in a spec-based solution is good for the Java ecosystem. Many people have noted that Spring and other frameworks already have these features, but they are important features to have in a spec-based solution (like Jakarta EE) as well, because spec solutions are multi-vendor solutions and not coupled with a specific vendor.

Conclusion

The interesting EJB features should survive, whether they have the EJB name or not. The idea of getting the interesting features from EJB and distributing them to other specs with more affinity is amazing and means we will have these important features in the Jakarta EE, but in lighter and more organized APIs. This is a good chance to evolve the Jakarta EE feature set to promote lighter, more cohesive Jakarta EE components and APIs.

Note: All content in this article is my opinion and does not necessarily represent the views of Red Hat.