I am a Java Developer working in Sydney. I am eager to learn new technologies, new frameworks, new languages. Thibault has posted 8 posts at DZone. You can read more from them at their website. View Full User Profile

Spring vs Java EE: What People Forget About Spring

  • submit to reddit


A few days ago, I was listening to episode 85 of the Java Spotlight Podcast. In this episode, Bert Ertman and Paul Bakker were talking about migrating from Spring to Java EE. Basically, in their introduction they were saying that, nowadays, there is no point choosing Spring over Java EE. We can read it in their article:

It took a while but Java EE has finally made the leap to be a standard, lightweight, fitting solution to the vast majority of real-world development challenges in the mainstream enterprise applications space. You should have no single reason beyond choosing the standard.

Over the last couple of months, I have seen a lot of blog articles with similar thoughts. Some are praying for Java EE, which is a good thing, while others are just denigrating Spring. This is the case of the article of Arun Gupta. My first thought on this article was "Oracle might be really desperate to write such trolls...". I am not at all a Spring evangelist, nor a Java EE hater. On the contrary, I have used intensively Java EE 5 for two years and am really happy to see it rise as a competitor to Spring. My goal is not to pray for Spring here, either, just to balance the words of the "Spring haters."

Standard- VS Single-vendor solution

Is it good to have standards?

Do you know the sentence "Responding to change instead of following a plan"? It is one the Agile rules. It is not only good to have standards, it is fundamental! But it comes with its drawbacks. If one day you have a problem with a standard because of something not covered by that standard, your only solution is to fill an issue, cross your fingers and wait three, or so, years.

Are Spring and standards incompatible? Not at all!

That is one of the reasons I do not understand the "It is standard" argument. Spring does its best to provide the use of the standard. You are free to use JPA, the CDI annotation, etc. I consider Spring more like an integration platform that lets you use all Java EE technologies and also some additional features provided by Spring itself.

Do I depend on SpringSource? Not really.

What happens if tomorrow SpringSource stops developing Spring? I know I will continue using it. Spring Framework is under the Apache 2.0 license, and the community will undoubtedly take the relay - companies will be sure to offer support for Spring users. Even if nobody does that, I am happy with Spring Framework in its current state. Why would I change? Maybe I will reconsider it in three years when a new version of Java EE is released ;) What happens if tomorrow I am not happy with Spring Framework? The same thing than if I am not happy with Java EE: I stop using it. If tomorrow I am not happy with my application server, the same thing will happen. I'll change it. Spring gives me more choices, though (since Spring works with all Java EE application servers and others, like Tomcat Jetty, etc.).

Spring has always been and will always be

I will never forget that Spring has made CDI possible and easy for Java web development. Java EE has followed (again three years later) with the JSR-299. Spring is also currently providing some awesome solutions that JavaEE is not:

  • Spring Data (Really nice especially for the NoSQL world)
  • Spring Social (Woops... JSR-357 has recently been rejected)
  • Spring Mobile

Some of them are in the plan of the next versions of Java EE (Yay! We will have it in three years!) while others have still been disregarded, or rejected altogether.

Integration Testing

One of the common arguments for Java is that you don't have to use mocks. You can do in-container testing thanks to Arquillian. I am definitely in favor of in-container testing instead of mocks, and Arquillian is a great tool. Arquillian is nice for Java EE but it is not Java EE! It has no standards and so you depend on a single vendor, JBoss (redhat), which makes the "It is standard" argument pointless. Then it is possible to test spring with Arquillian. At least, even if it is not perfect, Spring has the merit to provide something like that.


I have not focused my article on the enhancement provided by the Java EE platform, nor on the different features implemented by each. That wasn't my goal. I still believe that Java EE is a really good product and that it has finally become a serious competitor. But when I read "While Spring was revolutionary in its time [...], it really is last generation's framework - some people are even calling it legacy" that really annoyed me. How can someone say that?! Maybe it was just to create a buzz.
Published at DZone with permission of its author, Thibault Delor.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Jonathan Fisher replied on Mon, 2012/07/16 - 2:28pm

I completely agree with the points above! The two remaining "sore spots" in JEE are a decent security API (JEE security is atrocious when compared to SpringSec and Shiro) and we're waiting on the 2.0 versions of JMX and JMS. Other than that, JEE has largely taken the lessons from Spring and made them into an incredibly lightweight standardized API.

Reza Rahman replied on Mon, 2012/07/16 - 5:53pm

#1. Let's stay away from the name-calling please and stick to technical points. Arun is a pretty balanced guy, as are the vast majority of folks you seem to be referring to as "Spring haters". If you disagree with them, please clearly state why and leave it at that...

#2. Java EE is not a walled garden. Like all standards worth their weight, one of the prime objectives of Java EE is to encourage a healthy ecosystem of plugins that build upon it. This means that if a requirement is not sufficiently addresessed by Java EE you should be looking to solutions that build upon it like Seam 3, Apache CODI, DeltaSpike, PrimeFaces, RichFaces, Hibernate (OGM), Java EE centric Java.net projects and the numerous other vendor extensions (yes, maybe even Spring). You can even choose to extend Java EE yourself: https://speakerdeck.com/u/mojavelinux/p/hacking-java-ee-cdi-extension-writing-n00b-to-l33t-javaone-2011. I can assure you Java EE centric projects are not wanting for solutions to the security, NoSQL, social or Mobile questions, for example.

#3. Given the fact above (#2), the velocity of Java EE is really just about right. Any faster and there is a definite danger you would end up with immature standards with bad/incomplete APIs that wind up squashing innovation (that's essentially what happened in the very early days of EJB CMP). All good standards do and should take time.

#4. I can't find mention of anyone that suggested Spring is incompatible with Java EE (again, see #2 above) or that you are "dependent on SpringSource". What has been said is that unlike Java EE, Spring is not an open standard with multiple compatible implementations, which is plain truth.

#5. CDI is not in any way "insipred by Spring". It does not take too much effort to see that CDI bears far more resemblave to Guice and Seam 2 than it does Spring. That isn't a coinsidence. The developers of CDI did not see Spring as a good solution and rather opted to take their time and develop something better and then standardize it. Also, if you are trying to suggest that Java EE does not innovate, that couldn't be farther from the truth. It's very easy to point out innovations that have first appeared in Java EE and have been adopted outwards (yes, in many cases by Spring).

#6. As to Arquillian, see point #2 again. The fundamental reason something like Arquillian cannot be standardized is because JUnit/TestNG are not standards themselves. That being said, Java EE does everything it can to enable extensions like Arquillian (+JUnit/TestNG), like standardizing embedded containers. Also, no one said you couldn't use mock objects with Arqullian. In fact, that's almost the entire point of CDI Alternatives. Also note that it is perfectly acceptable to do unit testing without Arquillian and with vanilla Java EE APIs if that is what one wishes to do.

Kindly don't take any of this personally. It's a honest/straight-forward critique as to what I see lacking in your post, for whatever the underlying reason(s).

Sura Sos replied on Mon, 2012/07/16 - 6:49pm

I don't see why you need to follow Java EE standard to make your application compatible with the standard.

If a popular, well supported library works for you then use it. Standards keep evolving, it is not perfect.  With incompatibility comes innovation, at the end everone wins. Think about how Hibernate and spring changed JEE.



Thibault Delor replied on Mon, 2012/07/16 - 8:19pm

My article has been moderated, removing all touches of humor, some arguments, changing the meaning... Do not hesitate to visit my blog to have the original version...

Reza, I agree with you on most points. I admit that my article lacks of a lot of things, that's why I explicitly wrote that I have not wrote for example about the good points of JavaEE. Doing a full comparaison would required a book.

#1. I like to quote people, not matter if I agree or not. I think it gives a more human dimension. The term "Spring hater" is maybe too much.

#2. I agree JavaEE is a good standard and a good standard needs time. I can assure you Java EE centric projects are not wanting for solutions to the security, NoSQL, social or Mobile questions, for example. Sorry but I strongly disagree on that.

#3. All good standards do and should take time. Exactly! That is exactly what I am saying...

#4. That is something I have heard several times in conferences, podcasts, etc. I am pretty sure that in the podcast I pointed out, they also say that.

#5. Spring has implemented first the CDI concept. Java EE has then followed and I don't believe it is a coincidence. Java EE has implemented it differently and I agree with you, in a better way. It was just to point out that projects like Spring bring innovation. 

#6. Again, I agree with you, not everything can be standardized, that's a limit. My point was that JavaEE does not offer any way to do integration testing, you have to rely on external tools, while Spring has a solution. I didn't get your point on "unit" testing. I mean, you do Java, so yes you can do unit testing...


Even if I don't agree on everything, I really appreciate your answer. You really don't need to try to convince me on JavaEE, I am already convinced. It is just that he really annoys me to read things saying "Spring is dead" or "Spring is legacy", it is pointless to denigrate one product for trying to sell your own product. The problem of Arun is that he talks in the name of Oracle and, once again, in my opinion, that gives a really bad image of both Oracle and the Java community.

Sivaprasadreddy... replied on Mon, 2012/07/16 - 9:23pm

In addition to that the guy who said   "While Spring was revolutionary in its time [...], it really is last generation's framework - some people are even calling it legacy"  don't know how to develop a simple Spring app and have to copy the code from krams.blospot.com and saying Spring is dead..funny.

If he don't know how to develop a simple app using Spring  then how can he say JavaEE is better than Spring!!! To campare them atleast he should be hands on both of them.

Sivaprasadreddy... replied on Mon, 2012/07/16 - 9:30pm

At the same time   Bert Ertmanand Paul Bakker article series is awesome.. by reading through their articles we can say that they are not saying just like that.. they explained with real examples which exibits their real experience..

Shailendra Kumar replied on Tue, 2012/07/17 - 12:17am

Very insightful article. The “standard solution” argument put forth by EE Evangelists is bit shallow when viewed in context of practicality. Indeed Spring is a great integration platform and will survive.

Michal Xorty replied on Tue, 2012/07/17 - 2:48am

We switched to Spring because J2EE sucked. Now Java EE brings subset of well thought facilities inspired by Spring. But to make me switch to Java EE it has to offer MORE than Spring. But it doesn't. Why would I throw away years of experience of Spring? 

In our current project we are heavily using Spring Integration, Spring Security and Spring Batch. Can you tell if Java EE 6 offers something comparable here? It doesn't!  

Adi Sesha replied on Tue, 2012/07/17 - 4:28am in response to: Reza Rahman

'I can assure you Java EE centric projects are not wanting for solutions to the security, NoSQL, social or Mobile questions'

I was involved in development of more than 10 J2EE/JEE applications, for every single application security is priority.Assume that, today, the other technologies like NoSql,mobile etc may not be required for my project(except social other things are must for my project) but can you be sure that they are not required tomorrow? What do you suggest then, wait for JEE to evolve.


 'The developers of CDI did not see Spring as a good solution'

In what way? Please point me to performance metrics, clean code, facts. 

I am not against standards or JEE. I made sure my project uses JSR annotations for JPA, Validations, REST etc with underlying di container as Spring, deploys in JBoss 7. J2EE standards sucked for so long. At that time Spring, Guice and other non standards libraries eased the pain of development.Because JEE is evolved today, you expect us to migrate all our old applications to JEE which provides the same functionality? 


George Jiang replied on Tue, 2012/07/17 - 8:59am in response to: Reza Rahman

#5. CDI is not in any way "insipred by Spring". It does not take too much effort to see that CDI bears far more resemblave to Guice and Seam 2 than it does Spring.

 CDI injection happens when an bean is instatiated, just like Spring. Seam 2 injection happens at every method call. Like Spring, CDI uses proxy to inject short scoped bean (e.g. request scoped) into long scoped bean (e.g. session scope).

 I don't know the inside stories as who copied who, but CDI is definitely much easier to understand for developers who have used Spring DI than those who have used Seam2 DI. At least it appears CDI has copied from Spring instead of Seam2.

Back to you.

Jose Delgado replied on Tue, 2012/07/17 - 11:21am

Hi  tibo,
 On the referred quote...
"It took a while but Java EE has finally made the leap to be a standard, lightweight, fitting solutions to the vast majority of real-world development challenges in the mainstream enterprise applications space. You should have no single reason beyond choosing the standard."

I really-really want to believe it... But,  first I would like to see some showcases/live demos.  I am not expecting a regurgitation  of the petstore again. I am expecting showcases handling hundred of thousand of records  with acceptable performance. Showcases on Java mobile, showcases in social networking, showcases on NOSQL, etc.

I know they are going to ask me to show my showcases. That's fair, my Spring Framework 3.*  showcases are located at http://pragmatikroo.blogspot.com. It includes 2 live demos, some video tutorials and more 50 articles  on state-of-the-art Java Enterprise web development.
While I don't see acceptable showcases about JEE 6 I will consider it as just "wishful thinking"

Thank you
jD @ http://pragmatikroo.blogspot.com

Reza Rahman replied on Tue, 2012/07/17 - 2:35pm

It does not make much sense for me to answer basically the same questions on a piecemeal fashion, so I'll make a synopsis of what I think is worth responding to:

#1. Please keep in mind that Arun has a lot of latitude in his work. Oracle does not micromanage what he posts on his blog. Spring is not the bible or the Quran and SpringSource is not the Holy Catholic Church. The way I see it, it is perfectly acceptable to express an opinion that is not favorable to Spring, including suggesting that Spring filled a gap that now no longer exists, raising the valid question whether Spring really needs to exist any more either. You are free to disagree with that viewpoint, but I think it is important to maintain due respect for a differring opinion.

#2. I don't think there's a point quibbling about integration, batch, security, mobile, NoSQL, and social support in Java EE based projects. Whether a given individual is ready to agree with it or not, the facts from a Java EE standpoint are that it is possible to effectively meet these requirements with tools like container-specific security, Seam Security, JBoss ESB, Seam Schedule, JAX-RS, Hibernate OGM, EasyCassandra, Seam Social and so on. In fact, for my own projects, I've solved almost all of these problems quite effectively with no Spring whatsoever. All one has to do is free oneself of the mindset that all solutions must be somehow a Spring module or that Java EE must meet all application requirements without appropriate plug-ins/extensions and start looking around for practical solutions with an open mind, including pulling up your sleeves and integrating native APIs yourself using CDI portable extensions.

#3. Trying to suggest CDI bears more resemblace to Spring than Guice and Seam 2 is also just quibbling that I am not all that interested in engaging in either. The fact is that almost all the core DI ideas in CDI originate from Guice (perhaps except for Producers that originate from "bijection" in Seam 2), while the interceptor and context management features come from Seam 2. The rest of the concepts are genuine innovations in the CDI EG that have no direct counterparts in Spring. For those not interested in quibbling and want to know a bit more about CDI, here is an interview with Gavin that talks about the roots of CDI and how it relates to Guice: http://www.infoq.com/news/2009/11/weld10.

#4. To see how CDI/Java EE differs from Spring, I would start with my slide deck that Arun references in his blog (here it is for easy reference: http://www.slideshare.net/kelapure/java-e-evsspringshootout). I believe the strengths/weaknesses of each solution is pointed out quite clearly there. If you still have questions, feel free to email me -- I am not hard to find...

Shane Johnson replied on Tue, 2012/07/17 - 1:06pm in response to: Jose Delgado

Have at it:




Jose Delgado replied on Tue, 2012/07/17 - 2:31pm in response to: Shane Johnson

Hello Shane,

 Now we are talking...

  Yes, I like your 3rd link from the top. It would serve your cause better if you populated with as many-many records  as possible though.

I tried the  mobile-ready link shown and... It didn't work in firefox, in chome 3 menus are shown -but when I clicked on them nothing is activated-  nothing is shown when used in my android phone.

I am not pretending to be your QA source or give you hard time... but if you guys are going to show case your flagship technology, I really recommend to come up with something as close to the real-world production thing.

 I'll take a look to the soucecode provided.

 As a courtesy,  I kindly request from you to vist my Developer blog and come back and post anything you want.

All feedback is welcome for me. The link is http://pragmatikroo.blogspot.com

Seriously, I might be wrong but with the links provided I don't think JEE 6 is better than Spring 3.

 Thank you

jD @ http://pragmatikroo.blogspot.com/?view=timeslide







Michal Xorty replied on Tue, 2012/07/17 - 4:54pm in response to: Reza Rahman


Actually, there is a huge point. Could you honestly tell us, why should we throw away solution (Spring), that:


  • is used by more developers and businesses,
  • is more mature, has more experienced professionals, more literature, more features,
  • is able more quickly respond to needs of the developers (doesn't need to wait couple of years to introduce standards)
  • .... ?


Shane Johnson replied on Tue, 2012/07/17 - 5:40pm in response to: Jose Delgado

OpenShift is currently undergoing maintenance. TicketMonster should be up later tonight.


That being said, Java EE and Spring are not front end frameworks. I don't think you can compare two different back end frameworks based on the look and feel of the front end. That is where the front end frameworks come into play and the role of designers becomes apparent.


That, and I don't think you can really compare whether Java EE is better than Spring 3 or not before you have evaluated the back end source code.

Shane Johnson replied on Tue, 2012/07/17 - 5:58pm in response to: Michal Xorty

Perhaps you could cite the evidence that supports your statements?

Regarding the wait...

03/2006 - Spring 2

11/2007 - Spring 2.5

12/2009 - Spring 3

That is a couple of years between Spring 2.5 and Spring 3.

Reza Rahman replied on Tue, 2012/07/17 - 7:59pm in response to: Michal Xorty

Yet again, whether you agree with it or not, the reasons as I see them are well-outlined in my slide deck, including the issue of "mindshare" which I haven't seen to be a problem, especially in the IT/Java world - after all this is the argument that was once used in favor of Struts 1, J2EE, C and COBOL (and even in favor of Flash against HTML5!).

Personally, I left Spring behind since Java EE 5/Seam 2 and haven't looked back since. As a one sentence simplification - I find Spring to be overly-complex, configuration-heavy, bloated and proprietary and I prefer the simplicity, choice and vendor-neutrality of Java EE. If I wanted a single-vendor solution, I wouldn't have chosen to be a Java developer in the first place :-).

Yet again, I think the pace of Java EE is quite sufficient (roughly 2-3 years, which about covers the duration of a project after the initial technology set is chosen), as long as you actively do your research and are familiar with the very rich, diverse, community-driven, responsive ecosystem that supports Java EE (including actively participating in the JCP) instead of passively taking technolgy queues from a single company. GlassFish, Resin, TomEE, Seam, CODI, RichFaces, Arquillian, PrimeFaces, etc for example all have roughly one/two releases per year, which is more than adequate for most projects.

Please try and respect my time and kindly don't repeat questions I've already answered. If you disgree with me, please plainly state why and move on. Otherwise, please do expect that I will ignore you :-).

Jose Delgado replied on Tue, 2012/07/17 - 6:49pm in response to: Shane Johnson

I did it already... In fact I recreated the showcase as "ticketRoo"...

On the other hand. I would say Spring is more on the have-the-job-done kinda category... more than back/front end this-and-that. In my opinion.

BTW. This is  TicketRoo roadmap

   1) Backend done!. All entities up and running CRUD mode. Screenshot shown below.

   2) Next iterations

          2.1) Enable MPeg and Video streaming in MediaType using NOSQL

          2.2) Enable very nice look and feel Web 2.0

          2.3) Showcase tables population and QA work.

          2.4) Tutorial on how to move to Spring 3 from JEE 6 using Spring Roo

 B. Roogards

jD @ http://pragmatikroo.blogspot.com



Reza Rahman replied on Tue, 2012/07/17 - 11:36pm

Since this is predictably a circus already anyway, I guess it can't do too much more harm to throw this in the fray too: if you happen to be going to JavaOne this year, there are actually a number of sessions on this very topic:

1. CON6430: Java EE and Spring Framework Panel Discussion - Richard Hightower, Bert Ertman, Arun Gupta, etc.

2. CON5066: Migrating Spring to Java EE - Paul Bakker, Bert Ertman.

3. CON10659: Migrate from Spring to Java EE 6: Approaches and Techniques for Spring Developers - Marius Bogoevici, Arun Gupta.

I have no doubt these will be full-house sessions. So if you happen to  be interested, you should probably RSVP for them as soon as possible.

Note: To be clear, I personally now consider this a very stale/uninteresting topic that there is a ton of material out there on already. I believe folks that write/speak about Java EE should now be spending their energies elsewhere such as demonstrating real life success stories, educating people on the Java EE ecosystem beyond the spec itself and tackling the remaining bits of anti-Java EE FUD. Indeed that's exactly what my JavaOne sessions/articles this year and next year are about...

Michal Xorty replied on Wed, 2012/07/18 - 12:57am in response to: Shane Johnson


I think the timing between the major releases of Spring framework are reasonable. What is the difference though, that Spring is not only a core Spring framework, but also bunch of other Spring projects like Data, Security, Mobile, Integration, Batch etc.

So when you quickly need say social networking support - we don't have to wait for major release of Spring, but side-project is released by SpringSource that smoothly integrates with main Spring framework.

From my point of view this is good - it keeps major releases well prepared and quickly changing enterprise needs satsified.

To say it in one sentence: Spring (unlike Java EE) doesn't only solve problems of yesterday, but quickly adapts to problems of today.

Michal Xorty replied on Wed, 2012/07/18 - 1:07am in response to: Reza Rahman


 thank you for your reply. Unfortunatelly you failed both answering my questions and convincing me. In my opinion, there is really no point of switching to Java EE yet. As I pointed above, it's less mature, it has less features, less literature and less experienced professionals. Even though Java EE obviously improved, it's not enough to switch back from Spring unless it offers something significantly better. And it doesn't (yet).

Anton Arhipov replied on Wed, 2012/07/18 - 8:46am

it doesn't make sense to standardize upon nosql since the implementations are so different

Reza Rahman replied on Wed, 2012/07/18 - 9:32am

Yep, exactly. That's the point about NoSQL Emmanuel makes well in the Hibernate OGM blog: http://in.relation.to/Bloggers/StandardizingJPAForNoSQLAreWeThereYet. Personally, I'm not even sure any kind of abstraction over the various NoSQL products are needed at all (like Spring Data attempts to do to try to "Springify" things - no surprise there, they seem to have a compulsive need to put Spring abstractions over everything :-)). The story is much the same with Social Network APIs (which is why the JCP rejected a proposal for a Social Networking JSR), although Seam Social is probably a step in the right direction, as are the other various CDI plugin projects out there. That's very different from more mature areas like batch processing that are now being standardized in the Java EE timeframe as a formal JSR...

Shane Johnson replied on Wed, 2012/07/18 - 11:13am in response to: Michal Xorty

You just described the JBoss ecosystem.

JBoss AS 7 / EAP 6 is not a monolithic Java EE 6 implementation. It is a modular implementation that that includes of a number of projects: Hibernate, HornetQ, Infinispan, JGroups, PicketLink, RESTEasy, and RIchFaces to name a few. These projects maintain their own release schedules, and they add their own new features above and beyond the specification util such time as they are adopted by it.

Spring was, in fact, created to solved yestereday's problem.

The problem with Spring is that you have to wait for a new project to use something like MongoDB since a new Spring configuration / API has to be created. With Java EE, you can use the Java API of your choice. You dont' have to wait.

Shane Johnson replied on Wed, 2012/07/18 - 11:17am in response to: Anton Arhipov

That is true at a hight level. Perhaps not at a low level.

If you divide NOSQL into key/value store, document store, and column family database then standards would be helpful. Very helpful.

Shane Johnson replied on Wed, 2012/07/18 - 11:36am in response to: Michal Xorty

You did point that out above. And once again, you did not provide evidence to support your claims.


How about literature?

Spring: 40

Java EE: 123


That doesn't include books covering JPA, JMS, JAX-RS, JAX-WS, JSF, and the rest of the Java EE components...




Liam Knox replied on Sun, 2012/07/29 - 2:32am in response to: Reza Rahman

As always, Rezza == a 'standard' trumps a deliverable.  Hibernate, much as its flawed, was always better than JPA and as a standard superior.  Same you can say for log4j etc etc on top of the prescribed 'standard'. Best 'standard' that came from the whole Java space (Sun/Owner) since day one was JDBC.  The rest, baring the language its self, is pretty sub standard.

 I cant wait for the next 'standard' so to see which ways the lemmings jump. 

'Springify' equates in this context to make an application work. Without an Oracle database , Application servers , Network stacks , bad web API's, messaging technonogies or a JCP aka a  'blessing from Christ (knows what)' to be ordained as a 'good' technology'.




Liam Knox replied on Sun, 2012/07/29 - 2:41am in response to: Shane Johnson

Java API of your choice?  So I can use java.io to do java.util?

You do sound like you have no idea in what you are talking about.  Spring leverages open source API's to fit in with a well defined framework.  J2EE ( Java ) tries to invent API's based on no business experience.  

Can you define a yesterday problem? What did they solve? Smallpox?

Reza Rahman replied on Thu, 2013/01/17 - 5:13pm in response to: Liam Knox

As usual, Liam == (outdated, irrational anti Java EE FUD + childish personal attacks). JPA is a far cleaner, more modern API than Hibernate. That's why the Hibernate team itself recommends it, not to mention the fact that JPA offers vendor-neutrality.

There are plenty of good APIs in Java EE, that's why folks are adopting it: https://blogs.oracle.com/stories/, even if favor of Spring: http://www.slideshare.net/ertmanb/javaone-2011-migrating-spring-applications-to-java-ee-6. JSF, JAX-RS, Bean validation, CDI, WebSocket, etc are all examples of standard APIs that more than hold their own against any non-standard solution.

All views voiced are my own, not necessarily Oracle's.

P.S.: You should really pay a bit more attention -- my name is Reza not "Rezza".

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.