Comment by hello_moto | Hacker News Reader

Comment by hello_moto | Hacker News Reader

Parent Full thread

Maybe it's preference/bias but I found the latest Java EE6 offers a lot simpler programming model than its predecessor or Spring.

I also prefer to stick with 1 container as opposed to mix-n-match Spring modules + Hibernate + Apache CXF/Axis2 or whatnot. Most libraries out there boasted that they implement the JSR standard but they don't stop there as they also added their own extensions + configurations.

There are a few missing parts in Java EE: MVC and dealing with NoSQL which both will be addressed in Java EE7 from what I know. Spring has SpringMVC and SpringData so they're ahead right now.

What I don't like from Spring is the complexity of the setup (dependency, albeit Maven helps) and knowing various Spring modules and how they works with your preferred app-server. With Spring, at some point, you need to know a few key integration points between Spring and your app-server. For example: deploying an EAR solution that contains multiple WARs and JARs would require to understand Spring lifecycle, setup/configuration if you'd like to behave according to your requirement.

A plus point using Java EE6 is to trim down your EAR/WAR. Spring pulls many JARs.

That's a fair point, I guess I've been spoiled. I guess I just don't mind knowing those integration points and working with them, but I can definitely see how it would put a bad taste in your mouth after a while.

The NoSQL integration I think will be big. I know some folks using SpringData to talk to MongoDB and they've had positive experiences so far.

Maybe in the future things will get simpler - so far I've found that I'm pretty happy with either embedded Jetty or Tomcat. And then Spring/Jersey + Hibernate/JPA.

Have you found that EAR/WAR size has hampered you? I tend not to worry about how many JARs I'm pulling.

I use GF3.1 as they are the only one that implement JEE6 in full. There's an issue with deploy/undeploy app (memory leak due to pushing ClassLoader to the edge) which is kind of annoying to me personally because we do frequent build/deploy. I wish we can use Jetty (I used Jetty, Servlet, GWT in my previous company) since it is way leaner and faster to reboot; especially via Maven.

Although I've never measured the deployment performance, I'm quite sure the smaller your EAR/WAR size the faster it deploys because the ClassLoader is required to scan + load those libraries (again, it depends on the behavior of your library: up-front or lazy loading).

I recently moved from Glassfish back to good old Tomcat because of this classloader leak. With GF, I could typically do no more than 1-2 redeploys before having to kill -9 it. That was really painful. We found that we weren't really using many GF/JEE features that couldn't be added to Tomcat as a simple jar dependency (J2EE connection pooling was one nice built-in, but we'll use c3p0 or something similar soon). Tomcat is a breath of fresh air- starts/stops in < 4 seconds, and redeploys never hang.

You definitely want to try jrebel to solve your problems with redeploys and wasting time. It'll reload your classes and resource as you compile/provide them. Check it out, http://zeroturnaround.com . disclaimer: I work there, but jrebel is awesome anyway.

I have heard of JRebel for a while but have not had the case to need this until now. Is it free for development?

PS: I saw someone from JRebel did a presentation about ClassLoader before, you guys really know what you are doing. Respect man! :)

Reply on news.ycombinator.com