Java EE 6 vs. Spring 3 stack

Question

I'm starting a new project now. I have to choose technologies. I need something light, so no EJB or Seam. On the other hand I need JPA (Hibernate or alternative) and JSF with IceFaces.

Do you think that such a stack on Spring 3 deployed on Tomcat is a good choice? Or a Java EE 6 web application could be better? I'm afraid that Java EE 6 is a new technology, not well documented yet. Tomcat seems to be easier to maintain than Glassfish 3.

What's your opinion? Do you have any experiences?

Solution 1

I need something light, so no EJB or Seam.

Would you care to explain what makes EJBs heavy since EJB3? Do you realize that we are not in 2004 anymore? I'd really like to read your definition of light and your arguments (and I will update my answer with pleasure because I'm pretty sure I would have a few solid things to say).

On the other hand I need JPA (Hibernate or alternative) and JSF with IceFaces.

Java EE 6 Web Profile which includes JSF 2.0, JPA 2.0, Bean Validation, EJB 3.1 Lite, CDI,... would be perfect for this and you can use GlassFish v3 Web Profile to run an application built with the Java EE 6 Web Profile.

Do you think that such stack on Spring 3 deployed on Tomcat is a good choice? Or a Java EE 6 web application could be better?

Well, I like the idea to run my code on a non-proprietary platform (Java EE) rather than on a proprietary container (Spring). And I think that Java EE 6 is good enough (and this is an euphemism, EJB 3.1 (Lite), JPA 2.0, JSF 2.0, CDI kick ass). Note that I was a JSF skeptic but I took a second look and JSF 2.0 with CDI is so different that I can't even compare. And if you didn't look at CDI, let me tell you that it rocks.

I'm afraid that Java EE 6 is a new technology, not well documented yet.

Java EE looks pretty well documented to me. This sounds like free claim. And, believe me or not, I start to find Spring getting complicated while Java EE getting easier.

Tomcat seems to be easier to maintain than Glassfish 3.

Did you try something? Did you face any particular problem? Again, this sounds like free claim.

Solution 2

I have not used JavaEE6.

However, I have been beaten up badly enough by all the previous versions of JavaEE and EJB's that I won't trust it until it establishes itself as the de facto standard, not just the de jure standard. Right now, Spring is still the de facto standard.

Fool me once, shame on you. Fool me twice, shame on me. Fool me three times, EJB.

Some will claim that Spring is proprietary. I would argue that the vendor implementations of the JavaEE specs have been just as proprietary, if not more so.

I went through a major conversion recently of moving a bunch of Java Applications from JBoss to Weblogic. All of the Spring/Hibernate apps ported with zero modifications, because they had all the libraries they needed built in. All the apps that used JPA and EJB and JSF were a disaster to port. Subtle differences in interpretations of JPA, EJB, and JSF between appservers caused all kinds of nasty bugs that took forever to fix. Even something as simple as JNDI naming was completely different between AppServers.

Spring is an implementation. JavaEE is a spec. That is a HUGE difference. I would prefer to use a spec IF the spec was 100% air-tight and gave absolutely no wiggle room in the way vendors implement that spec. But the JavaEE spec has never been that. Maybe JavaEE6 is more air-tight? I don't know. The more you can package in your WAR, and the less you depend on AppServer libraries, the more portable your application will be, and that, after all, is the reason I use Java and not Dot-NET.

Even IF the spec was air-tight, it would be nice to be able to upgrade the appserver without having to upgrade all my technology stacks in all my applications along with it. If I want to upgrade from JBoss 4.2 to JBoss 7.0, I have to consider the impact of the newer version of JSF on all of my applications. I don't have to consider the impact on my Spring-MVC (or Struts) applications.

Solution 3

It doesn't matter. Java EE 6 is good enough and because of the profiles there, it is not "heavy" - you'll just be using the web profile.

Personally, I prefer Spring. But I'm running out of rational arguments against Java EE 6 :)

(As I was reminded by a comment - you might want to try RichFaces, as well as ICEfaces and/or PrimeFaces - depending on what components you need).

Solution 4

Recently, one of my client assignments involved evaluating Spring Stack Vs Custom framework stack Vs a Java EE Standards. After a month of evaluation and prototyping, I was not just happy but blown away by the Java EE 6 feature set. For any new "enterprise" project architecture in 2011 and going forward, I would go with Java EE 6 and potential extensions like Seam 3 or the upcoming Apache JSR299 extensions project. Java EE 6 Architecture is streamlined and incorporates best of many open source ideas that have evolved in the last several years.

Consider the following features out of the box: Event Management, Contexts and DI, Interceptors, Decorators, RESTful webservices, integrated testing with embeddable container, Security, and many more.

Most of my results are published in my blog explaining the key concepts of Java EE 6 that you might find useful.

Of course, there is no hard and fast rule for choosing a framework. Java EE 6 could be well bloated for simpler "web sites" that don't require a rich conversational session state. You might as well pick Grails or Play! Framework. But for conversational web applications, I can't see a better argument why Java EE 6 is not a good fit.

Solution 5

Now, after some time, I have experience with stacks :

• Java EE 5 + Seam + GraniteDS + Flex
• Spring 3 + Vaadin (on GWT)
• Spring 3 + JSF 2.0 (PrimeFaces)

My colclusions are:

• Spring 3 is much much simpler than Seam (almost Java EE 6) and runs on Tomcat and Jetty! (Jetty for developement with maven plugin is a trasure).
• I love Flex (I actually was a Flex developer for long time so I'm biased) and if you need rich interface and can buy FlashBuilder use this, but use this wich Spring + GraniteDS or BlazeDs backend. If you can't buy FlashBuilder don't waste your time.
• Vaadin is great!. Developement process is simpler than Flex, but you can create rich application easily without HTML mess. You wont't write a singe JS line. You just need some CSS (in Flex you need it too). So if your application interface is going to behave like desktop application and you can't (or dont want to) use Flex - use Vaadin. Warning! Vaadin has big JS overhead for browser.
• If you create simpler website-like application use JSF2.0 (with spring backend as above). You'll need to fight with HTML (I hate it) and creating rich interface will be harder than Vaadin (especially layouts). You will get lightweight HTML for slower browsers/compuetrs. I like PrimeFaces - it's easy and well documented. Second place is IceFaces
• If you create a website (NOT a web application) where you need to put life into HTML (instead of create enterprise application that fits into browser) use Wicket (if you prefer component based, pull attitude) or SpringMVC (if you prefer template based, push attitude) or just use Play! framework. Remember that creating rich data-based components will be much much harder but you will have control over each tag of html (your HTML/Graphics designer will love it)

View more solutions

Comments

[Piotr Gwiazda]

So the question is: "Does it make sense to use full-stack Glassfish Application Server just too use web profile" ?

[matbrgz]

Do you have Flex+Java experiences to share?

[Piotr Gwiazda]

I've created some applications with Java+Flex and PHP+Flex and I agree that it's the best solution for rich interfaces. But in this application I can't use Flex :( I need some high-level interface though, so Spring MVC is not a solution. I want to think about sortable datatable either than <tr> <td> in a loop.

[duffymo]

What does "high level interface" mean? Why is JSF acceptable and Spring MVC not?

[duffymo]

Flex + Spring + BlazeDS is a nice combination.

[Bozho]

@duffymo - I can argue whether flex is a good choice. JSF is definitely not dead, especially with libraries like richfaces, primefaces, icefaces, etc. around.

[Piotr Gwiazda]

In IceFaces I create menus, trees, datagrids use actions, events and I don't think if page reloads or is it ajax request. An sortable datagrid or ajax loaded tree is a buil-in component. In Spring MVC I operate on HTML - tables, lists etc. I need to use some third party javascript framework and create AJAX magic by hand. I'd like to do it in Flex but it's a political/business decision - not mine.

[duffymo]

@Bozho, I think it's dead because it's not used at all from where I sit. It's not about libraries. I think the mindshare is going to RIA technologies, not JSF. The one application that I saw using JSF was written so poorly and consumed so much memory on the browser that you could time page renderings with a sundial. The team that wrote it might not have been the best, but it wasn't a very inspiring start. JSF is deader than the proverbial doornail.

[Bozho]

My current two JSF projects are definitely not dead ;) And I'm way more satisfied with the JSF way to build RIA ("rich" in "richfaces" is for that), than using Flex. One is even going public next week.

[Devanshu Mevada]

@peperg Use GlassFish v3 Web Profile if you just want the web profile, see my answer.

[Devanshu Mevada]

I'd really like to know why you'd still prefer Spring, Java EE 6 is damn good. Don't you think that running on an open platform is important for the future of Java?

[Devanshu Mevada]

I do not agree with your first sentence, the choice is not about using JMS or not. And I don't think that JSR-330 is that important in Java EE 6 (it is more there for political reasons), the important part is JSR-299 (CDI). At least, this is my opinion.

[duffymo]

No, I don't. I think the calculus changed when Oracle purchased Sun. They aren't the same company. The fact that Spring has been closed for the ten years it's been evolving hasn't hurt the quality or my future at all.

[Devanshu Mevada]

Hmm... Spring, which is not ten years old, has taken a dangerous path very recently only (the past doesn't mean anything). And the Java EE standard isn't driven/owned by a single entity, Snoracle can't change this without destroying Java EE (which makes no sense IMO). I'm not following you.

[duffymo]

The open source availability of Spring isn't ten years old, but the development of the framework is. "Expert J2EE" was published in 2002, so the development of interface21 preceded the publish date. Are you referring to the VMWare purchase or the separation of the community and professional versions for Spring? I don't know about Oracle destroying J2EE, but it's certainly been dormant for a very long time now. Where's the new version of WebLogic? Where's Java 7? Nothing appears to be happening.

[Devanshu Mevada]

I'm referring to Spring being a proprietary container and to the proprietary tc Server. Regarding Oracle, digesting BEA and Sun will clearly take some time: WebLogic 12 has been announced for 2011, don't know for Java 7 (but I don't really care, I want to play with Java EE 6 first).

[duffymo]

But offering a proprietary container doesn't preclude using Spring with Java EE standard containers. BEA was purchased a while ago; the Sun deal only closed recently. WebLogic 12 in 2011? That's an eternity since WL 10 came out. I'm not sure that Java EE 6 will be adopted by conservative Fortune 500 companies until after 2011. There's a difference between developers playing with technology and adoption in the workplace. I think Spring is still worth considering: I can use it now.

[Devanshu Mevada]

That's an eternity since WL 10 came out Yeah, and even more since WebLogic 6 came out :) At least compare to 11g. But I get your point and it will indeed take some time before adoption of "major" Java EE 6 app servers, especially by Fortune 500 companies. Still, GFv3 (and soon JBoss 6, and more) may be an option for some people, like it is for the OP in the context of this question. The OP can use Java EE 6 now.

[Piotr Gwiazda]

I'm just after rater big project developed with EJB3.0+Seam on JBoss with Drools, GraniteDS and some more. I agree Seam rocks ! But I spent 50% of developement on redeployement, restarting servers, deployment errors, cleaning temp directories etc. On the other hand JBoss Tools performance was really poor (I mean really - ctrl+space and 10s hang) This realy discourages me to use JEE6 which looks like borrowed from Seam framework. As for server I don't want to think about conecion pools, jndi, jms, jmx, ear deplyment. I need something to put WAR on and run in seconds.

[Piotr Gwiazda]

CDI looks like copy-paste from Seam Framework (actualy project Weld IS developed from seam). I can get something similiar in Spring with SpringELResolver.

[Devanshu Mevada]

@peperg Gaving King is the spec lead of CDI (Weld being the RI) so you'll find similarities between Seam and CDI. But CDI != Seam, Java EE 6 != Seam, your perception is wrong. Maybe try GlassFish v3 Web Profile, you'll be surprised (and once the connection pool defined, there is not much to worry about).

[bes]

Agree there were some politics involving JSR330 - nevertheless it is quite important as it provides a common basis for dependency injection in Java (SE or EE) rather than making DI a JEE-only technology. Also, it is supported by Spring framework and Google Guice, which means it will make Spring/Guice code easy to port over to JEE6 or vice-versa. JSR299 was also designed to extend on the features in JSR330. You are correct in that for web applications in JEE6, JSR299 is absolutely crucial. Thanks to these two JSRs, JEE6 & Spring both have very similar programming model. Thanks for ur comment!

[Devanshu Mevada]

"Heavyweight processing"? Could you elaborate? I'm curious.

[Devanshu Mevada]

Yes, you can package EJBs in a WAR in Java EE 6 but this doesn't mean you can deploy such a WAR on Tomcat. You need a container implementing the Web Profile and Tomcat doesn't and there is actually no plan in the Tomcat community to implement it (see old.nabble.com/Java-EE-6-Web-Profile-td27715793.html). But there is GlassFish v3 Web Profile, there will be Resin...

[norgence]

I've posted some arguments here stackoverflow.com/questions/2822812/spring-3-0-vs-j2ee-6-0/…‌​, rather taken from the "how to take it into production" standpoint. So maybe that fills up your arguments reservoire a little bit.

[Piotr Gwiazda]

Thanks for Your comment. My choice was Spring + Vaadin.

[matbrgz]

@peperq, JBoss 6 was released over the holidays.

[arg20]

What is it with people saying EJBs are heavy?. I'm using EJB v3.1 and they are simply annotated pojos. When they say heavy do they mean in performance or what?

[Arjan Tijms]

@arg20 - That's indeed the big question and Pascal rightfully asks to explain what the term "heavy" (or "light") means in this context. Most likely it's a remainder of the old feud between Spring and EJB. In the early days, EJB1 & 2 were conceptually heavy. An overemphasis on remoting and stateful beans, a ridiculously verbose XML deployment descriptor and a totally insane amount of required interfaces to be implemented gave them a very bad reputation. With EJB3 (2006) this has completely changed, but people who left EJB in 2004 for Spring sometimes still think its 2004 and EJB2 is the latest.

[Arjan Tijms]

We're almost exactly one year later now and JBoss AS 6, which supports Java EE 6, is currently being used in production.

[Piotr Gwiazda]

I like your answer. Very reasonable. When I posted the question JEE6 was very young and Tomcat 7 wasn't finished yet. "original reasons that motivated Spring are no longer valid" - it's true, but JEE6 with CDI needs some time to cath up. For example: Javamelody monitoring is available for Spring and Guice (I can't imagine woring on applications without it). EHcache is available for Spring (I mean caching methods results). Lots of things like aspect programming are still easier in Spring, because lots of third party libraries and frameworks integrates easily with Spring but not with JEE6 yet.

[Pere Villega]

I don't see how your own answer relates to the question...

[Vítor E. Silva Souza]

Note that on Spring's about page it says "We believe that: J2EE should be easier to use". Note they use the term "J2EE" and not "Java EE", which has been the correct name since the release of Java EE 5 (I think). This says much about them...

[matbrgz]

It turned out that Java ServerFaces 2 in Java EE 6 could do on its own what we needed Tomahawk for with JSF 1. It is a quite capable framework (but a bit XML heavy)

[Rachel]

@PascalThivent: I have similar situation and I would really like to know your views on stackoverflow.com/q/9263251/164299

[user359996]

-1 It seems very inappropriate to accept this answer, since it doesn't even mention Java EE 6. Moreover, it doesn't address any of the points raised in @Pascal Thievent's well-thought-out (and much more highly voted) answer.

[Palesz]

Java EE 6 is just freakin' slow, glassfish and glassfish web profile is just really slow to start comparing them to jetty/tomcat/whatever. Testing, embeddable container is also really slow.

[Palesz]

Exactly, this is a great reasoning.

[Piotr Gwiazda]

Actually question is not more valid. JEE 6 is now very mature, it wasn't in March 2010 when the question was asked.

[joshua]

The year now is 2012.... Its fun reading the comments made in 2010

[ymajoros]

@PiotrGwiazda in what way did JEE 6 change since then? People were more afraid of it back then, but it was basically the same JEE 6.

[Piotr Gwiazda]

I meant that JEE6 implementations are more mature and available. JBoss 7 is now stable and there are more implementations available. Community is larger now too. More tools and libs now support JEE 6 stack.

[Peter Porter]

I agree with this reasoning, many problems I've faced have been with dependencies on a container's implementation of a spec. Significantly less pain from embedded libraries. Hard to argue, outside of the philosophical preference of a spec.

[Soumya]

Wonderful reasoning. However is this your experience even after JEE 6? I understand App Server implementations of specs can still be a pain - hence the same spec implemented by App Server 1 may be a simple and efficient while not for App Server 2

[gpilotino]

update: take a look at TomEE+ project tomee.apache.org/apache-tomee.html

[Nathan Hughes]

+1. also, the application server changes on Operations' schedule, where spring/hibernate is under the control of the developers. in a big company environment upgrading the appserver is a much bigger deal.

[timmz]

Great point, unfortunately people tend to forget that software are made to live for decades and that long term support is a crucial key.

[Sergey Podolsky]

I didn't really get the point about Dot-Net. It is as much propriatery as Spring and is developed by a single vendor which is Microsoft. Could it be explained please?

[Beaker]

I wasn't jabbing at Dot-Net for being proprietary. I was jabbing at it's lack of portability since Dot-Net applications only run on Windows...or at least run best on Windows.

[Alexandros Maltezos]

the word is thrice*