Take the 2-minute tour ×

Hi guys : I've used JSP/Servlet frameworks pretty broadly, generally picking up Java EE tricks when necessary (for example, when my data access code get complicated, I usually adopt Ibatis/Hibernate ; or when my UI gets ugly, I start using tools like guice/spring DI to simplify testing) .... However, I've never seen the point in a "full" Java EE stack --- usually most applications only need one or two of the typical Java EE features.

My question is : What is the benefit of full blown Java EE containers ? It seems like running a standard tomcat server, dependency manger, in the context of a daily test/builds cycle is capable of managing complexity pretty effectively, in my experience.

My thoughts :

1) Maybe Java EE stacks like glassfish/jboss are more scalable (i.e. they can be easily extended to handle higher volume with out spot coding or ad-hoc optimizations) ?

2) Maybe Java EE stacks are more modular (i.e. they can communicate with other Java EE components that were built for different contexts ?)

3) Maybe Java EE stacks allow seamless interoperation between different features (for example, maybe JMS interoperates cleanly with JPA data operations, so that you don't have to "manually" glue different system components together...) ?

Any thoughts on these suggestions would be appreciated ... I'm somewhat new to heavyweight Java EE frameworks and am trying to contextualize their usefulness over simpler, homegrown mvc code-bases.

share|improve this question
purchasable support from a "name brand" vendor and management interfaces that operations people don't complain about (as much), forsrs. –  Affe Nov 18 '11 at 21:17
funny how in all my years of experience when things get complicated we usually start ripping out hibernate and spring and what not, in all seriousness I guess you haven't gotten to that side of the complexity curve yet. –  Jarrod Roberson Nov 18 '11 at 21:48
I don't think Hibernate is worth it, but I've never ripped out Spring. What's the alternative - writing your own? Crazy. –  duffymo Nov 19 '11 at 1:11
And I love those snarky, passive agressive comments like "I guess you haven't gotten to that side of the complexity curve yet." As if the rest of us are just writing "Hello World." Maybe I'm just better at dealing with complexity than you are. –  duffymo Nov 19 '11 at 1:13
add comment

closed as not constructive by BalusC, Jarrod Roberson, Don Roby, user7116, ChrisF Nov 22 '11 at 12:21


4 Answers

up vote 2 down vote accepted


How is that a reason not to use a Java EE container, though?

One thing you have not mentioned is declarative transactions, you definitely need those. Spring can do that too, but from what I've heard it takes some extra work to get distributed transactions.

Which leads use to the topic of clustering, which EJB containers have built in according to the standard. If you need scalability at the service level, it takes very little work if you're running on a Java EE server. If you use Spring, there are some third-party solutions, but not a standard.

And there's all the other APIs that are part of JAVA EE - JMS (Messaging), Java Mail, JAX-B (XML binding), JAX-WS (SOAP web services), JAX-RS (REST web services). If you use a Java EE server, you can be sure that it has implementations for all of them ready and integrated should you need them. Sure, it's also possible to get each of them and integrate them into your Spring-based or homegrown solution, but I'd say you're rather more likely to run into integration problems or just simply produce a mess.

share|improve this answer
add comment

The most common use case is that not everybody needs a full blow application server.

Java EE 6 gives the concept of server profiles



See a comparison of suggested profiles, to get an idea.


share|improve this answer
add comment

This is a pretty open-ended question. They scale just fine. Are they more scalable? More scalable than what? More modular than what?

Homegrown solutions are rarely a long-term solution (or at least a good one). Most EE functionality can be replicated using existing libraries/frameworks/servers, but it's often more work than using an existing EE container--but it may also be (a) enough, and/or (b) better.

Modern Java EE is pretty slick. It has reacted to the challenge laid down by Spring, and is now a more realistic choice than previously. Is it the right choice? Depends on the app, the in-house skills, what types of infrastructure you can/want to support, you name it.

share|improve this answer
add comment

First of all, it's "Java EE". "J2EE" is 1999 terminology.

Second of all, servlets and JSP are Java EE. They're a subset.

I'll assume that "full blown" means EJBs (entity, session, and message-driven), JMS, etc.

I think that until EJB 3 came along that the full blown stack was a liability. That's why frameworks like Spring came into being. Rod Johnson wrote it because he noticed that his Java consulting gigs required something much better and simpler than EJBs. Spring helped him to drive revenue; now it helps all of us.

I'm a Spring advocate. I haven't used EJBs because I don't have a need.

share|improve this answer
add comment
