Spring vs EJB. Can Spring replace EJB?

Since Spring is able to use transactions just like EJB. For me, Spring is able to replace the requirement of using EJB. Can anyone tell me what are the extra advantages of using EJB?

Spring was developed as an alternative to EJB right from its inception, so the answer is of course you can use Spring in place of EJBs.

If there's an "advantage" to using EJBs, I'd say that it would depend on the skills of your team. If you have no Spring expertise, and lots of EJB experience, then maybe sticking with EJB 3.0 is a good move.

App servers written to support the EJB standard can, in theory, be ported from one compliant Java EE app server to another. But that means staying away from any and all vendor-specific extensions that lock you in to one vendor.

Spring ports easily between app servers (e.g., WebLogic, Tomcat, JBOSS, etc.) because it doesn't depend on them.

However, you are locked into Spring.

Spring encourages good OO design practices (e.g., interfaces, layers, separation of concerns) that benefit any problem they touch, even if you decide to switch to Guice or another DI framework.

Update: This question and answer are five years old in 2014. It needs to be said that the world of programming and application development have changed a great deal in that time.

It's no longer just a choice between Java or C#, Spring or EJBs. With vert.x it's possible to eschew Java EE altogether. You can write highly scalable, polyglot applications without an app server.

Update: It's Mar 2016 now. Spring Boot offers an even better way to write applications without Java EE app servers. You can create an executable JAR and run it on a JVM.

I wonder if Oracle will continue to support the Java EE spec. Web services have taken over for EJBs. The EJB solution is dead. (Just my opinion.)

First, let me say it clearly, I'm not saying you shouldn't use Spring but, because you are asking for some advantages, here are at least two of them:

• EJB 3 is a standard while Spring is not (it's a de facto standard but that's not the same thing) and this won't change in the foreseeable future. Although you can use the Spring framework with any application server, Spring applications are locked into both Spring itself and the specific services you choose to integrate in Spring.

• The Spring framework sits on top of the application servers and service libraries. Service integration code (e.g. data access templates) resides in the framework and is exposed to the application developers. In contrast, the EJB 3 framework is integrated into the application server and the service integration code is encapsulated behind an interface. EJB 3 vendors can thus optimize the performance and developer experience by working at the application server level. For example, they can tie the JPA engine closely to JTA transaction management. Another example is clustering support which is transparent to EJB 3 developers.

EJB 3 is not perfect though, it is still lacking some features (e.g. injection of non managed components like simple POJOs).

Pascal's points are valid. There are, however, the following in favour of Spring.

• EJB specification is actually a bit loose, and therefore different behaviours can be observed with different application servers. This will not be true for the most cases, of course, but I've had such a problem for some "dark corners".

• Spring has a lot of extra goodies, like spring-test, AOP, MVC, JSF integration, etc. EJB has some of those (interceptors, for example), but in my opinion they are not that much developed.

In conclusion, it depends mainly on your exact case.

Spring is meant to complement EJB, not to replace it. Spring is a layer on top of EJB. As we know, coding of EJB is done using API, which means we have to implement everything in APIs using the Spring framework. We can create boiler-plate code, then just take that plate, add some stuff to it, then everything's done. Internally Spring is connected with EJB -- Spring wouldn't exist without EJB.

The main advantage of using Spring is that there is no coupling at all between classes.