EJB3 or "Spring3 + hibernate" which one suitable

Question

There are so many things are common in in EJB3 and Spring 3 with hibernate. I need to findout where I can use Spring framework with hibernate not EJB3 and viceversa.

Retiform

Duplicate question? #69027 – Tapestry

@Tapestry Its not oonly Spring. It is Comparision between Spring + Hibernate and EJB3 – Retiform

Hibernate is an implementation of JPA spec for the persistence layer, so that means that in the EJB3 option you are not going to use JPA? – Tapestry

Answer 1

You can use them interchangeably.

If you go with EJB3, you'll have to have a full Java EE, EJB3 app server. Some are free, some are not.

If you go with Spring 3, you need to have the Spring JARs in your CLASSPATH, but a full Java EE app server is not required. Tomcat or Jetty are sufficient, depending on your needs.

There are multiple vendors for EJB3 implementations; after all, EJB3 is merely a specification. There's only one vendor for Spring.

Personally, I prefer Spring. I've used it for six years, since version 1.0, with great success. It's a very high quality framework. EJB3 took a great deal from the lessons learned by Spring and Hibernate. I think Spring's aspect-oriented programming is better than what has been added to EJB3. The other modules (e.g. security, LDAP, web services, etc.) are excellent.

Cottonwood

I agree (+1). There's hardly ever any compelling reason to choose JEE over Spring other than corporate requirements. – Therefor

@Cottonwood Apart from server reason, is there any specific reason like transaction management, EJB good in complex and distributed application as many things are implemented by sever vendor. – Retiform

Spring does transaction management; it can deal with complexity (since your code does that); it can be distributed. There is nothing that EJB3 can do that Spring can't, except collect license fees. – Cottonwood

>There is nothing that EJB3 can do that Spring can't, except collect license fees - So Rod gives us Spring without any commercial interests? Really? And Apache is collecting license fees because I use OpenEJB? Really? – Scarification

Spring was open source; you can still download the framework without buying support. "Some are free, some are not." Read the response before you spout. – Cottonwood

@duffymo: the "except collecting license fees", was IMO a troll that wasn't necassary. Both EJB and Spring have paid support and both can collect license fees. Above all Springsource (VMWare) is in it for the money, and Rod Johnson is a clever businessman. Spring may be okay as a technology, but your subtle hint about the fees makes it sound like EJB is still mainly sold by commercial vendors, while Spring is still the grassroots not-for-profit organization with the only goal of bettering the Java world. This is nonsense and you know it. – Angkor

Troll? Nonsense? Sounds like you're taking this too personally. Just for the record, you don't work for a Java EE app vendor, do you? The fact is that I've never paid a dime to deploy Spring on Tomcat, but my employers continue to shell out for WebLogic and WebSphere to the tune of millions. That IS a fact. Yes, it's possible to buy support for Spring, and you can use JBOSS or Glassfish if you wish to use EJBs. Rod Johnson is certainly in it for the cash. No one was happier than he when VMWare bought Spring Source. You are projecting far too much of your own feelings into my comment. – Cottonwood

Dyffymo, your point simply makes no sense. I've seen employers shell out big time for tcServer, since it's supposedly the place where Spring is supposed to run (their tagline). Maybe Springsource is a little bit embarrassed about the price they're asking, since it's not really clear on their site, is it? Mean while, I never ever paid a penny for using OpenEJB. And yes, that IS a fact! – Scarification

Agreed, I'm not denying anything, just speaking from my experience. I don't use tcServer. And we don't use OpenEJB. I can't speak for whether or not Spring is embarrassed - I'm guessing not. – Cottonwood

@Cottonwood Can you update this answer to reflect the current state of EJB? Something like this should work: "If you go with EJB3, you need to have the Embedded EJB Container JARs in your CLASSPATH -- a full Java EE app server is not required. A full Java EE, EJB3 app server is also an option. Some are free, some are not." As of EJB 3.1 you can use an EJB container in a plain Java SE vm like you can JPA -- we more or less copied that API when we add the same feature to the EJB spec. – Casebound

Answer 2

They are both rather similar. See this question as well: EJB 3.1 or Spring 3.. When to choose which one?

If you go with EJB, you can choose to target Java EE. This means that you don't have to include any extra jars in your WAR, since the target environment already supports EJB. Compare this with targeting Java SE, where you don't have to include classes like ArrayList and HashMap in your jar, since any Java SE runtime already has those.

Of course, you can also include EJB jars with your application, which is convenient should you want to target servlet containers likes Tomcat or Jetty. In that case OpenEJB is probably the best choice, but any EJB implementation can run its container in embedded mode (this is a requirement of the EJB spec) and is usable in Java SE.

There's also a version of EJB that's even more lightweight than the full EJB. This is called EJB3-lite and is supported by servers like Glassfish Web Profile and Resin. These are both barely larger than a bare Tomcat (Resin is 23MB) and give you a complete stack out of the box.

I personally think EJB3 is better than Spring. It's less complex and less heavyweight. EJB3 started a revolution with only requiring simple annotations and adhering strongly to convention over configuration. Spring historically required massive amounts of XML for even the most simplest of things. Spring however learned from EJB and is now adopting the same approach.

At the end of the day, both are mature and good technologies though and you can't go wrong with either of them (just avoid mixing them, unless you absolutely have to).

Scarification

You can use Spring with EJB; the other way isn't advisable. "Less complex and less heavyweight" - really? Massive amounts of XML - you haven't looked at Spring 3 and annotations. You fail to acknowledge the debt that EJB3 owes to Spring and Hibernate. – Cottonwood

Duffyomo, I partly agree with you about the debt, but there's a little more to it. EJB and Spring are in a lock-step with each other concerning innovation. In Java, EJB originally came up with the idea of container managed beans with cross-cutting services. The model however was invasive and heavyweight. Lots of XML was required. Spring simplified EJB by coming up with a pojo based approach, but required even more XML. Then EJB followed Spring, but simplified further by going all-annotation. Spring then followed EJB. EJB (via CDI) then innovated by introducing type-safe injections. – Ola

About the Hibernate debt, EJB isn't currently in debt to it, but JPA partly is. The relation is however rather obvious as Gavin King himself contributed to the JPA spec and Hibernate is JPA. More over, Hibernate didn't invent the model, as TopLink existed long before it. Hibernate was 'merely' an opensource alternative to TopLink. Members at Sun at the time (e.g. Mike Keith) actually proposed going with the TopLink model in EJB right from the start, but they lost out to the ones advocating the horrible EJB1/2 Entity bean model. – Ola

@duffymo: don't forget that Rod Johnson was given the opportunity again and again to contribute to the EJB spec. If we was truly trying to better the world and doesn't care about "collecting license fees", then why didn't he took this opportunity? – Angkor

As far as I know, you buy support for Spring. You don't pay license fees. I don't know if Rod Johnson or a member of Spring Source sat on the JSR committee. You'll have to ask Rod Johnson what his motives are for doing some things and not others. Rather than crying so publicly, I'd appreciate if you could point out something that you can do with EJB that cannot be done with Spring. And do let us know if you've got a hidden EJB bias. That would be helpful. – Cottonwood

something that you can do with EJB that cannot be done with Spring. Type-safe injection? Really simple to use? Completely annotation based without a single line of XML? It's not just about having a 1000 barely used features, it's about having a simple and elegant yet powerful design. Look at the iPhone when it first came out. Did it had more features than the average Nokia smart-phone at the time? Maybe not. Was it easier to use? Pretty much so! Something with kitchen sinks and so. – Scarification

I can inject by type. And I think Spring is simple to use. That's subjective. Got me on "no XML", but I don't think you can do Java EE without any XML. I think Spring is simple, elegant, and powerful. Kitchen sink? The features generally match Java EE. Sorry, you're ranting now. – Cottonwood

You can. web.xml is optional, faces-config.xml is optional and EJB absolutely does not need a single line of XML in what place whatsoever. I can just put a pojo in an arbitrary package in a simple war, ONLY put @Stateless on top of it, and I have the FULL power of EJB. – Scarification

p.s. you did make me curious. What often used powerful feature does Spring have that EJB doesn't have? I'm sure it has one, and I'm eager to learn about it. – Scarification

Spring and Java EE map 1:1 to me. I can't cite a hidden powerful feature. And I'll admit that I don't know the new Java EE spec well enough to know whether XML is entirely eliminated, but I don't see it as a big deal. I'm done now. This is one of those subjective conversations that SO doesn't encourage. – Cottonwood

@Scarification let us continue this discussion in chat – Cottonwood

No problem with chatting, but I think everything has been said in this case ;) – Scarification