Is EJB still used in recent applications?

[Rogerio Kioshi]

Hello,

I'd like to know if, nowadays, EJB is a technology that is still used. If a company plans to build a new app, EJB can be considered? Or are there better java technologies?

To "Core Java, Volume II" author.

[Tim Holloway]

Well, EJB is certainly alive and very well in Java Persistence Architecture (JPA). JPA is a subset of the EJB3 standard.

If you mean traditional EJBs with remote interfaces a là EJB 1.0, I can't say. I could see a use, but the original form as a remote application interface wasn't firewall-friendly and required a compatible Java client. RMI-IIOP helped on the firewalls, but performance was still an issue.

So maybe for intra-net use remote EJBs are worth consideration, but for general world-wide web usage, it's more likely that you' see JPA objects fronted by web services.

[Stephan van Hulst]

For me, it completely depends on who I'm developing for. If my customer maintains Java EE containers, I'd definitely prefer using EJBs for web services that use things like asynchronous tasks, transactions, scheduled jobs, etc. Java EE 8 has a wonderful API, and the services that you deploy can be smaller that equivalent services that you'd build using Spring, for example.

For simpler web applications that can run inside less complex servlet containers like Tomcat, you wouldn't use EJB.

[Claude Moore]

The problem with EJBs is that they still bear all the blame they gained with early versions - most of which they honestly deserved , so nowadays they aren't so much popular.
IMHO if you are working with an application server supporting a recent Java EE version there's no real reason to avoid  using EJBs 3.0. They provide transaction support, REST support, asynchronous call support for free.

[Tim Holloway]

Claude Moore wrote:The problem with EJBs is that they still bear all the blame they gained with early versions - most of which they honestly deserved , so nowadays they aren't so much popular.
IMHO if you are working with an application server supporting a recent Java EE version there's no real reason to avoid  using EJBs 3.0. They provide transaction support, REST support, asynchronous call support for free.

Yeah. In my town, the biggest shops bought into the fad of using Session EJBs fronting Oracle Stored Procedures. It was awful, not just performance-wise, but architecturally, and it contributed greatly to my decision that stored procedures should be only be used as a last resort.

I can think of only 2 other fad blunders of that magnitude: Building major systems based on CORBA (remember CORBA? Millenials won't get this!). And building major systems on OLE/ActiveX.

Although I suppose OS/2 gets honorable mention. If you ever wonder why high-level executives get such exorbitant salaries it's because they make incisive strategic decisions like a certain Fortune corporation based locally: "Get rid of all those Macintosh computers! We're going with a system that has a future: OS/2!" (almost a literal quote).

[Claude Moore]

Tim Holloway wrote:
I can think of only 2 other fad blunders of that magnitude: Building major systems based on CORBA (remember CORBA? Millenials won't get this!). And building major systems on OLE/ActiveX.

... and I would add Applet-based systems as well to the list of broken promises.
About OS/2, I think it was simply too eager of resources for the time it was released. I remember one of my friends that installed  it on his home PC and was desperated for the huge (for the time) quantity of memory it needed.

[Peter Rooke]

Just reading this and recalling some previous projects!  
EJB entity beans using CMP meshed in with all those J2EE design patterns    
I do think Sun made a mistake of continuing to use the Enterprise Java Beans name with the improved version 3.  

Here's a few humorous posts highlighting some of the "features" of these older technologies;

2004 A Workspace Odyssey (EJB2 CMP)
Totally Gridbag (GUI Swing)
S Stands For Simple (SOAP)

[Tim Holloway]

Peter Rooke wrote:
I do think Sun made a mistake of continuing to use the Enterprise Java Beans name with the improved version 3.  

Well, we're not talking "New Coke" here. The essential characteristics of EJB are still there. Just cleaned up. A LOT. No DTO's, for example. No need for an EJB-compliant container if you're just using the JPA part. Or for that matter, even a JEE container at all. JPA runs just fine in stand-alone Java apps, and I have lots of code to prove it.

[Claude Moore]

Peter Rooke wrote:
I do think Sun made a mistake of continuing to use the Enterprise Java Beans name with the improved version 3.  

Well, a bad fame is something you definitely have to deal with when selling something, and when you are proposing a technology stack, you must take in account how good a technology is perceived, not only how good a technology is. Keeping EJB name didn't helped, no matter that an Ejb 3 has nothing to share with the cumbersome complexity of Ejb 2.0. Something very similar may happen with Microprofile initiative.. Most of the programmers I know think that stuff isn't anything better than old-fashioned Java EE pruned here and there, and their approach is quite always "please, stay away from me".  Personally I believe that being able to choose which part of the Java EE (now Jakarta EE) adopt for your own real needs it's a good thing.Personally I think that if microprofiles were thrown in the IT arena years ago,  it would be a great benefit for Java  for enterprise context.

[Stephan van Hulst]

I am currently working on a hobby project that attempts to use as much of Jakarta EE and its reference implementations as possible.

I managed to get Jakarta EE 8 running on Java 11 in a WildFly application container, with my EJB modules using the Java 9 module system. Regarding technologies with a bad rep, I've made it my goal to use JSF as my template language (NOT to serve as an entry point for my requests, I'm using MVC 1.0 for that). In the past, I probably would have used Spring with a template language like Thymeleaf, but I think it's beneficial to try out the new cleaned up Jakarta EE technologies instead.