Skip to main content

Is J2EE Dead?

Posted by boneill42 on March 3, 2008 at 8:30 AM PST

I recently presented at the Philly JUG. In my presentation , I asked the question, "Is J2EE dead?", half-kidding, but mostly serious.

I've spent the last six months developing in Ruby (some on Rails). It quickly went from just a past time, where I was developing a silly little beer review site called liquidMirth to serious business applications (at the day job: rVooz). And now I have to admit, the compile, build, deploy cycle of a standard J2EE application seems unbelievably daunting. Combine that with the cumbersome and seemingly never ending twiddling of meta-data and deployment descriptor files required by the libraries and frameworks (e.g. Spring & Hibernate) that are supposedly helping the problem and you have an incredibly unproductive environment for web application development.

I'd emphasize that this is unproductive for web applications, because web applications need to be especially responsive to user requirements. J2EE simply isn't agile enough. There is a
fantastic video
by someone out at NASA JPL that does a fantastic job comparing the latest web application development frameworks. He does a great job emphasizing this point.

Now, all that said, J2EE != Java and Java's present sweet spot is in SOA, and business process integration, where things need to be transactional, and message-oriented/event-driven. Web frameworks are having trouble in that area, where things don't fit into a nice request/response interaction. On the "back-end" you need a bit more rigor, and typically you need to integrate with systems that won't conform to convention.

So, IMHO -- let more flexible languages accommodate the fickle nature of users. Use Java, with specifications like JBI and SCA, to implement an ESB on the back-end to do the heavy business process lifting, systems integration, and B2B style interactions.

And if you do that, you'll quickly realize that you don't need much (if any) of the J2EE spec to get-r-done. Instead, OpenESB in J2SE, ServiceMix, or Mule fill the bill quite nicely.

just two cents, and here is another nickel's worth of similar sentiment.

Related Topics >>


Sure. J2EE is dead. JSP is dead. Cobol is dead. Elvis is dead! Zed's dead baby, Zed's dead...

I think Groovy\Grails is a viable competition to what ruby/rails has to offer on an already proven scalable platform (JVM). But if you ever need to write scalable app without rockstart developers hacking the mongrel code then java as a platform with numerous offers such as teracotta, coherence is there as well. Best of all world! Check out the grails site on the rapid uptick of user interest on this framework.

A month or so ago I would have agreed with you, no question. However, now that I have spent some serious time with the Grails framework, I am falling back in love with web development in Java. No need for the compile, build, deploy cycle here, just make a change and refresh! I tried rails but didn't want to learn a new language. Grails uses Groovy but I can still leverage all the Java knowledge I have acquired over the years. Not to mention that Groovy is fun to use! Grails isn't J2EE so your argument still stands but, we don't have to sacrifice Java on the front end to remain agile!

+1 on the post and the comment. Couldn't agree anymore. BTW, I am currently on a JSF/Icefaces project and I have to say it's even worse than you can possible imagine.

The main goal of JavaEE 6 is to be able to bring a rapid development layer together with more solid foundations. A typical arrangement would be for scripting for the web tier with webservices/ejbs/jms/ below. Or intetgration using scripting. Or prototyping. GlassFish v3 is designed to enable this. A separate arrangement emphasizes non-Java languages on the (J)VM. Again, GFv3 is targetting that also. We already have JRuby, QUercus (PHP) and JavaScript; Grails is almost there; and today we announced two Python guys joining Sun :-) - eduard/o

smayzak, i agree completely. Sorry, i didn't mean to imply we should drop Java for webapp development. I'd certainly lump Groovy and Grails into the agile/rapid development frameworks. They rock.

And now I have to admit, the compile, build, deploy cycle of a standard J2EE application seems unbelievably daunting. JavaRebel addresses this issue, enabling Ruby-like development in Java -- make a change and refresh the browser. See the screencast for more information.

So now Sun themselves are jumping onto the "Java is dead" bandwagon and are themselves proclaiming what the enemies of Java have been screaming from the top of their lungs for over a decade?

Hi Ruby, and these kind of "toys" are nice for small things...But well...I love the power. Microsoft .net and Java gives you the power. But Sun must be the things going simpler, easier....The clock is playing and the time is nearly over for java...We should get some like "J2WE (java 2 web edition) with one small set of apis to make simple web sites that run nearly with a click. Anyway to say the true...Things are now much easier than one year ago. Will all the respect...rails doesnt look serious ¿Can you write pdfs with rails? ¿Powerfull graphics? ¿Easy integration with flex?....etc. Dont bring me limits...i want all the power, i want Java and Microsoft

I will repeat what I have been saying for some time now in several forums. Either Java kills Spring or Spring kills Java, and I am not talking about competition. It will kill Java by scaring all the developers away to some scripting language, and guess what, they are right in running away. If I had to work with Spring I would probably want to kill myself.

Spring is horrible and it adds so much cruft to Java development that even the simplest things get difficult. Besides, the basic premise of "eliminating dependencies" is flawed, because you can't eliminate them, you just move them from Java code, where they are explicit for the developer to see, to XML or, even worse, Annotations.

Hibernate is the reinvention of the wheel. We already have a perfect language for querying databases, it is called SQL.

The problem is, Java is blamed for all the insanity of Spring and HIbernate. You may notice that the main points used against Java are respectively EJB (which nobody will ever need in simple site), Spring and Hibernate.

Six month ago I might have agreed, but my current Ruby-on-Rails project went pass a threshold of complexity which makes me want some proper static typing and less "Cool" features. Some safe refactoring (you never have enough tests to compensate, and if you did you'd spend most of your time maintaining them), some "where is this method called"... the works. Can't get it in Ruby, and I use it a lot in java development.
Rails is fine for slightly-more-than-trivial systems. For me, there are too many "cool" features that bite you when you look the other way. The ability to add "=" to methods ( def my_foo=(arg).... ), coupled with the "we're too cool to to declare variables" approach, means you have to explicitly invoke your own methods using self ( as in self.my_foo=x ). And that's from a language whose aficionados call java "verbose".
Another example is the ||= operator, which is usually read as "initialize the left hand variable unless it is already initied". This works pretty well, until your left hand side was initialized with false. And since it is dynamically typed, you'll have hard time finding that bug. I know I did.
Too cool for me. Sorry guys, next large project is in spring.

Couldn't agree more with thiagosc. I have been saying exactly the same while discussing at work and I get ridiculed! Spring is nice but the way it is used for everything these days, is evolving into an 'anti-pattern' by itself! We as developer community don't learn from the past, do we? Hype/buzzwords are the key to advancements at work and not maturity/reasoning/doing the right thing. Sad, but from my long experience I can say one thing for sure, the good stands the test of time, everything else falls along the way. So cheers and keep doing the right thing.

Mucking with deployment descriptors is definitely bad. But if that's your biggest grief, maybe you are doing yesterday's EJB? I use JSF (Woodstock) + JPA with NetBeans and GlassFish. The JPA annotations are easy. The JSF faces-config file is dumb--I'll use Seam next time. In many cases, I can hotswap code changes (thanks NetBeans!). GlassFish has hot deployment for pages, so I can just copy my changed pages and reload. (Hello NetBeans...couldn't you do that for me?)

After years of waiting, the components are finally there. Last week, I needed a "bubble help" component with AJAX (which I do not care to program by hand). It took 3 lines of code to put in the Woodstock component.

I couldn't are less about the hideousness of the EJB spec or how much/little of it I am using. Obviously, I am using more than Tomcat and less than the full EJB--something like that middle profile that was in the blogs last week.

Maybe jlorenzen can share some of his JSF/IceFaces grief for the opposing point of view?

eduard/o, i agree. my "beef" isn't so much with the app servers (e.g. Glassfish), but more with the J2EE spec itself. If I'm using scripting on the front end (python, ruby, etc.), and I"m using other specs to achieve web services (via annotations perhaps), then how much of JEE am I really touching? Tomcat has been incredibly successful, because it is a Java-based app/web server, but how much of the JEE spec has it implemented over the years?