Java EE 6 vs. Spring 3 stack [closed]

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).