March 17th, 2010 by Lincoln Baxter III

Why doesn’t (JPA, JMS, JTA, EJB, JSF, CDI) work? JEE is “Too Complicated”

First, before reading this – you’re going to be upset with me. You’re going to disagree. I know — it’s OK. You may not even believe me, but you might keep reading because anger inspires action.

Stop using Tomcat and wondering why JEE “doesn’t work.”

You’re doing yourself a big disservice. Start thinking about JBoss AS 6, or GlassFish v3 — Yes, I know, it’s a “Full JEE Container,” — it’s “Heavy,” but with JEE6, that’s not a bad thing: It all “Just works” and it works really well. Trust me, the reason people have thought Java EE sucks, is because they try to do this stuff on Tomcat, and say “Why doesn’t (JPA, JMS, JTA, EJB, JSF, CDI) work?” Well… that’s because Tomcat only gives you Servlet – the Request/Response lifecycle. So people install all these things manually, or try to, and then say, “Wow, Java EE is really hard to use, shit, I’m gonna use Spring or Grails instead.” Tomcat, Jetty, and other “Servlet Containers” all have these issues – that’s why they are called Servlet Containers. If you really want to build everything from the ground up, piecing in parts of Java EE here and there — then go for it, but if you want it to work right away, then… well, I’ve said my part. Ever tried to use Java Mail on Tomcat? I think we’ve all been there… you need to steal the JAR from another appserver, or get a 3rd party implementation. Sure, it’s easy, you can do it… but why should you have to? Please remember when submitting flames: I do know that there are a lot of legitimate reasons to use Tomcat, it’s a great Servlet container. If that’s what you choose, good for you, I think you’re wasting time if you’re trying to get bits of JEE to work, though.

In my experience.

I wrote a fully functional JSF 2 application in 5 minutes. I created a new web project (Maven, Jboss Tools eclipse plugin (For easy JBoss AS 6), Netbeans, glassfish eclipse plugin, whatever) I created an index.xhtml file, and I was running JSF. Wow, that was easy, right? I even installed PrettyFaces and had Pretty URLs and URL Rewriting working in about 2 minutes – i recorded a video, only minor edits. My WAR file was 5kb — yes, Kilobytes. Now I wanted to use CDI and EJB – I made a Cron-like scheduler – idea taken from Adam Bien‘s JEE Patterns example – that sent email notifications to (nobody) “Subscribers:”
public class SubscriberNotifier {
 private Date started = new Date();
 @Schedule(second="*/30", minute="*/1",hour="*", persistent=false)
 public void sendNotifications()
 System.out.println("Notifying users subscribed to posts. First notification sent: "
 + new PrettyTime(new Date()).format(started));

I did use PrettyTime to format the date object into something human-readable, but that’s not really relevant to JEE. The point is –  I had a background service running, using EJB Scheduling – with full transactional and persistence support (if I chose to use those) up and running in as little time as it took to write a dumb little class and put two annotations on it. The JEE container automatically picked it up, and started it when I started my application.

And then I thought, “Wait, when did this get easy?” EJB used to make my heart shrivel inside my chest.

It’s all going to get even easier, too, when JBoss Seam 3 Framework starts releasing more of our development modules. I’m working on the Faces, Servlet, and Internationalization modules personally.

Now that my elevator speech is over 🙂 If you already use JSF 1.2, now is the time to upgrade — migrating to JSF 2.0 should be pretty simple. All you need to do (unless you use some 3rd party component libraries) is change your XML schema in faces-config.xml, version from 1.2 to 2.0.
<?xml version=”1.0″ encoding=”UTF-8″?> <faces-config xmlns=”” xmlns:xsi=”” xsi:schemaLocation=”” version=”2.0″> </faces-config>
And you will be running with JSF2. Once you do that, you should definitely try out CDI (Weld) – it’s IMPRESSIVE. Trust me… if you’ve tried, or heard of Spring – you’re going to like this. PS. You can also get use the plug-in for JBoss AS 5 for JBoss AS 6; get it the via “Install additional server adapters” link in Eclipse’s “New Server” dialogue.

Final thoughts:

Note: As a followup, I’d also like to add that the JCP – “Java ‘Corporate’ Process” really needs to be re-evaluated. It needs to be placed in the hands of the community in which it was supposed to stand for so long. Oracle has this chance – and it must not blow it if the good things we all love about Java, JavaEE, the JVM, Tomcat, Grails are going to continue moving forward with healthy competition and innovation. I call for the JCP – “Java Community Process” to become an independent foundation like Eclipse – public TCKs, free intellectual property, true community participation (open mailing lists, forums, wikis) – WITHOUT the need to print and fax a 7 page JSPA document to Sun in SanFran. I’m calling for a place where Java and JavaEE documentation are provided to, and by, the community – a site like I’m not the only person asking for this. Oracle – I’m holding you accountable for the future of Java, JavaEE, and the JVM. In the words of the human torch…


Lincoln Baxter, III

About the author:

Lincoln Baxter, III is the Chief Editor of Red Hat Developers, and has worked extensively on JBoss open-source projects; most notably as creator & project lead of JBoss Forge, author of Errai UI, and Project Lead of JBoss Windup. This content represents his personal opinions, not those of his employer.

He is a founder of OCPsoft, the author of PrettyFaces and Rewrite, the leading URL-rewriting extensions for Servlet, Java EE, and Java web frameworks; he is also the author of PrettyTime, social-style date and timestamp formatting for Java. When he is not swimming, running, or playing competitive Magic: The Gathering, Lincoln is focused on promoting open-source software and making technology more accessible for everyone.

Posted in Java


  1. Edwin Commandeur says:

    JBoss has been switching around the way they do stuff with just about every major JBoss release and I found it is not trivial to move an application from JBoss 4.0 to JBoss 5. Then I also found that the messy documentation of JBoss configuration is not so nice if it doesn’t do what you want.

    Also, JBoss and the like is nice if you only need to support one container, but if you want your app to be portable you do not want to be writing configuration files for every different server. You want to write your configuration once, as with Spring. Spring is easy for years. Java EE only with it’s latest reincarnation. Too little too late!

    1. Alexis MP says:

      @Edwin : the great thing about Java EE is that you don’t have to use any given implementation 😉

      @Lincoln, thanks for the thought-provoking blog.

  2. Lincoln says:

    What are you doing that you are writing server-specific configuration files?

    In my opinion it’s, “Better late than never.”

    Java EE is a hugely popular framework. Spring was successful because it simplified development and led the way for dependency injection. They also did a good job of marketing Java EE’s failings, and providing alternatives, without attempting to fix the platform itself.

    That’s not a bad thing, it’s just the reason Java EE has the perception it has today. (Don’t get me wrong, the failings were real, but the framework is far from dead, and is easier to use than ever. There’s still need for Spring, too, but Spring is in everything these days. Java EE is learning, fast.)

    Long story short, you shouldn’t have to be writing Container-specific configurations; I’m interested to know what specifically about JBoss you encountered.

  3. Doug says:

    Oh yeah. Easy = Bloated software
    We use Tomcat because it is lightweight. Nowadays when most projects try to stay away from EJB as far as possible, what is the reason to stick with a full blown AS?
    I have been using Weblogic, Websphere. Those are commercial products. They are getting bloated and slower each and every release. I told my management to get rid of EJB, switch to Spring RMI, use Tomcat. We saved bunch of money, time, and headaches. BTW dont tell me you write this because Redhat is paying you. Be true to your heart dude!

    1. Lincoln says:

      I did write this because the ideas are mine 🙂 I’m sorry you’ve been using WebSphere, it really does a lot of things wrong in my opinion.

    2. Paul youngh says:

      Funny you cite websphere and weblogic, but fail to mention eg JBoss AS, Apache Geronimo and Glassfish.

      Those are all free as in free beer, open source and have published design documents. They are all less heavy weight then tomcat + 100 added jar files (jar hell!). Glassfish starts up in mere seconds and war or ear files for it are just a few kb and are able to do so many things!

      Bye bye Tomcat with your 100+ jars that I have to maintain and welcome Glassfish that gives me everything right away!

  4. Gabriel says:

    JEE (no matter what version) works fine for some cases like those you described, but for many other cases it can get really painful compared to using a Servlet container and adding the dependencies manually.

    The root causes of the problem as I see it are 1) JEE will always contain only the subset of the available implementations which is acceptable by all members of the JCP (for example both Hibernate and TopLink are much more powerful when not constrained to JPA) and 2) JEE will always be lagging after the technologies that actually make the breakthrough (EJB 3.0 and 3.1 follow development model and implementation which was introduced by Spring years ago), so the more time passes after new JSRs come out, the more chance you will find better non-standard solutions.

    The real problems pop up when you get conflicts between dependencies from the applications you deploy and the JARs that come with the application server, and you can’t always upgrade the JARs without breaking the application server. I had the misfortune to run into this problem, I’m not just making it up. It is much less likely to happen with Tomcat since it contains very little JARs and it’s unlikely that they will conflict with the deployed application’s dependencies.

    I would summarize it like so: use what works for you, there is no rule of thumb here, and you can’t cast the simple demo cases on real world cases specific to your problem/application/organization.

    1. Lincoln says:

      Exactly – use what’s right to solve the problem. In the end, that’s got to be the answer. I just happen to think that Java EE 6 has *finally* done things right, and made programming apps simple and quick again.

  5. Tobias says:

    I’ve worked with JEE as well as Spring and I have to say that so far I prefer Spring. It does everything JEE does and then some – improvements available with the next release, not in x years when the next JEE spec gets finalised. True, there where improvements in EE from 3.0 to 3.1. But honestly, when do you expect a developer who’s stuck with WAS 6.x to benefit from this? Upgrading an appserver is way more visible to management than using a new version of spring-soandso.jar and those guys usually operate on a strategy of “never touch any system – no matter how broken it may be”.

    Another thing is that upgrading from JSF 1.2 to 2.0 is not as easy as you try to make it look. One could surely just change the config and call it a day, but JSF is about components – any thoughts on how to migrate a Richfaces based application? And no, 3.3.3 is not what I want, that’s like running an AWT app on JRE 1.6 and sell that as an upgrade.


    1. Lincoln says:

      Agreed – there are a lot of component suite issues to work out. Part of this was because of the problems in JSF 1.2 where people effectively had to replace and use implementation details in order to get functionality that users expected.

      Spring is great – don’t get me wrong – but also consider: Spring TC stack is just another app-server. You buy support for that and you’re going to have to wait for that next patch before they’ll support you on that new cool thing 🙂

      I agree JEE needs faster release cycles. That’s a problem with the JCP that I’m pushing for – extra pushing from others is appreciated 😉

  6. Rick says:

    Well, this is a courageous post for a JBoss guy (considering all the GlassFish love). But it’s true– GlassFish and Netbeans have made JEE programming fun again (if JEE ever was), I hope JBoss is right alongside. Competition is good, I hope these two keep raising the bar again and again.

    Thanks for the nice post.


    1. Lincoln says:

      Thanks Rick – I’m glad to hear that I’m not alone. I really was so pleasantly surprised by JEE 6 on GlassFish in Netbeans.

      I’ve got my eclipse enviroment set up to that point now too, but downloading Netbeans was all I had to do to get JEE 6 working, a running web-app.

      JBoss tools plans to be just as easy – but, it’s lagging slightly – it’s a smaller team 🙂

  7. For about two years I implement everything in Spring and Glassfish v2. Yes, I know, I am masochist. I love the Spring way… until Glassfish v3. Only after I port a JMS consumer from Spring to JEE 6 I believe in what Lincoln Baxter write here.
    Try that: take some server service (in REST, btw) and port it to JEE 6.
    Than come here again.

  8. Peter Thomas says:

    >> Ever tried to use Java Mail on Tomcat?
    >> I think we’ve all been there… you need to
    >> steal the JAR from another appserver, or get
    >> a 3rd party implementation. Sure, it’s easy,
    >> you can do it… but why should you have to?

    Yes this is easily managed using Maven and without the bother of having to ensure that any extra JAR-s you need don’t conflict with the container ones. In my experience, it is always easier to add libraries instead of removing them (or even worse – end up with multiple versions lying around in the classpath).

    Need to upgrade a JAR? Just change your Maven pom.xml. Yes, a container with everything you need out of the box does have its place in the “enterprise” – but some people can’t wait for the next official release of the app-server when a show-stopper bug gets fixed in “jsf2.jar” or something.

    1. Lincoln says:

      So upgrade that JAR in the App Server 😉 or use Maven and Tomcat; however, don’t complain too hard when the stuff is hard to set up 😉

      Everything does have its place, I completely agree! There are always options. Options are a good thing.

    2. Paul youngh says:


      Always easier to add a library? Really? Try telling that to the guy who has to maintain that 100+ jars on Tomcat. I tell ya it ain’t pretty…

      Do you also advocate that we all just download the Linux kernel and add (and maintain!) all extra libs that make it a desktop or server environment? Or do we just download Ubuntu or Redhat and be done with it? You tell me!

      1. Peter Thomas says:

        Huh ? “maintain” ? WTF are you talking about ? You make it sound as if you have to apply patches and compile “100+” jars, LOL.

        Sounds like you haven’t heard of Maven at all. BTW, the original blog post itself said “sure, it’s easy, you can do it”.

        Oh, excuse me, I gotta go re-compile me a new Linux kernel now 😛

  9. Sakuraba says:

    If you were ever held back by an app-server that provided services to you that you didnt need at all, then you would think differently.

    Would you accept your operating system’s boot time to be 5 minutes if it spent that time loading stuff you never use? What if there was an other operating system that allowed you to use only what you need and start up real fast? Would you use the heavy one or the other?

    1. Dominik says:

      Well, then try out glassfish v3. It only loads, what it really needs, all the modules are osgi bundles… startup in a few secs, not minutes.

    2. henk says:


      As Dominik already mentions, what if you had an operating system that offered tons of useful stuff, yet still loaded in mere seconds? Would you still rather use an OS that offered nothing but some bare bones functionality and also booted in seconds?

      If the latter is true, do you really start up a bare bones Linux kernel and take the pain and time to add each and every bit of functionality your self? Or do you just download Ubuntu? (or buy Windows or OS X)

      We all know that nobody but the most die-hards actually boot up a bare kernel. The overwhelming majority of users, including the technical savvy, just use a complete OS and maybe tune it a little afterwards here and there for services that are started but perhaps not needed.

  10. Dick Fagger says:

    How do you configure the scheduling parameters of the SubscriberNotifier if you don’t want to recompile the whole application?

  11. Sakuraba says:

    Oh and another thing: Spring Integration testing. I have yet to see a JEE-alternative to that.

    1. Jason Porter says:

      JBoss Arquillian [] is very close to what you would get with the spring integration testing. It currently runs in JBoss AS6 and Glassfish (I believe). Other app/servlet servers/containers could be added pretty easily as well.

  12. Dimitris says:

    Stop using Tomcat and wondering why JEE “doesn’t work.”

    But that would turn me shameless! So no. Just no!

  13. Christian says:

    I think Java EE 6 is just the beginning of a greater movement. There is still much old stuff in Java EE, like the somewhat outdated EJB remoting. And I don’t think that we don’t really need such a big umbrella specification like Java EE – that’s not the intent of modularization. I think Java EE should become a small core API with AOP support managed by an OSGi runtime.

  14. Tim Jansen says:

    I believe the reason why people are using Tomcat rather than a complete JEE server is that they DON’T KNOW all those three-letter-acronym frameworks (JPA, JMA, JTA, EJB, JSF, CDI). JEE is huge, and there is hardly any publically available documentation for it.

    Basically you have the choice between complete overload (API Docs and several thousand pages of specifications) on the one hand, and documents that hardly scratch the surface (Sun’s JEE tutorial and JBoss’ Getting Started Guide) on the other hand.

    Compared to this, Tomcat is attractive because it is relatively small. Servlets, JSPs and JDBC is all that you need to know. And, even better, there haven’t been any major changes in the last 10 years.

    Spring adds many of the capabilities that you will miss in plain Tomcat. And even though Spring is relatively large now, there is only one framework, and a single, free, easy-to-understand but still comprehensive ‘Reference Documentation’ for it. I think pretty much everyone who ever used Spring learned it from that document.

    While I would totally agree that JEE5 and 6 are great frameworks, they are still too hard to learn. There is not enough free documentation to show people how to work with it. And the API documentation and specs are literally *contaminated* with old backward-compatibility crud from the J2EE age that you don’t need to know to start a new application, but still makes up 80% of the documentation and confuses the hell out of people.

    1. Lincoln says:

      Tim, I completely agree — the documentation situation in Java EE 6 is completely unacceptable, and if you haven’t seen my last post, it’s something I’m dedicated to fixing, getting right.

      Any community needs use-case driven, well written, vetted documentation in order to be successful – everyone knows it, but the JCP has failed to make that possible. It’s time for changes in the JCP, or “Java Corporate Process” as I like to call it 😉

    2. arjan says:

      Tim, you don’t really have to know what those three letter acronyms mean half of the time. Just use the stuff!

      Java EE 6 is a wonderfully integrated whole. EJBs are now super easy and you really don’t have to know a lot about what EJB is and what it stands for to use the @Stateless annotation on a POJO and enjoy the wonders of default and super-easy transaction management.

      With Tomcat and all those libraries that YOU have to add to make it useful, YOU really have to learn about all those technologies in order to make the choice to start adding it to your custom stack in the first place.

      With Java EE 6, it’s just there and you adopt more stuff in your own application on an as-needed base. So you don’t need JMS right and don’t know what it is? Fine, don’t use it. But when you do decide you need asynchronous messaging and learn that JMS does that, all you need is already there.

      And please don’t give me that sh*t that Servlet, JSP and JDBC is all you need to know. That just silly. Even the most die-hard Tomcat fan used tons of added libraries (Spring, Wicket or Play!, Hibernate, yes JTA, etc etc).

      In addition to that, with Java EE you can actually stick to Servlets, JSPs and JDBC if you want. Nothing in the platform forces you to use JSF, JPA or EJB. But, IMHO you are seriously shooting yourself in the foot if you don’t use them and instead have some misguided idea that Servlets are all you need to know because that is what we have always used in the past. Sorry, but that’s just really really silly.

      1. Jason says:

        What people who say, all we need is servlets, JSP and JDBC don’t get is, they are simply a strict sub-set of JavaEE.

        If you use Servlets, JSP and JDBC you ARE using JavaEE, you are just not taking advantage of all the good stuff it gives you.

  15. Ahhh finally someone dares to expose to the world things i am convinced since i use glassfish !!!

    Thank you 🙂

  16. Edwin Commandeur says:

    Hi Lincoln,

    About container specific configuration. It starts with jboss-web.xml, which is pretty well documented. But then when you want to do classloading isolation that is just broke in the latest JBoss community releases ( With an undocumentend jboss-classloading.xml I could get some stuff to work, but Hibernate was a fail. JBoss contains some old Hibernate jars that it wants you to use and it forces you to do stuff in the new EE way, whereas previous configurations (that worked in JBoss 4) break.

    Security is also a thing that you can do with JBoss specific configuration (in server.xml/jboss-web.xml/login-config). In that case I rather use Spring Security than JBoss SX security, as Spring Security is very versatile, easy and portable.

    Minor bummer: startup time for JBoss went up from JBoss 4 to JBoss 5 :(, whereas for other containers startup time seems to go down.

    I agree on the remark above that adding jars you need is far easier than removing jars you don’t need. Also much easier to keep up to date if a bug is found.

    1. Lincoln says:

      Well Spring and Seam security both work on top of the JEE platform, so no real problems there 😉

      Also, it looks like your bug is finally resolved in JBoss AS 6.0! 🙂 Woot! Classloading issues are a HUGE pain, don’t get me wrong – it always depends on your business needs, but, you do always have the option of swapping out jars from the container itself (well… usually.)

      Startup time is something I’ve been throwing around to some of the guys on the AS team — I agree, it needs to be more like GlassFish, and start up in a few seconds, not 30 seconds.

      That’s why WebSphere kills me, too.

      1. Jason Porter says:

        The JBoss AS6 M2 startup is down to ~20s for me on 1.6.0_17, could be faster on _18 (I hear there’s some more improvements at the JRE level). AS6 M3 should also see big improvements in startup and runtime performance as well. Since AS5 performance has been a real sore spot for the team. The switch to the micro-kernel was supposed to promise reduced startup time but instead it became *much* worse. They’re now really addressing it. By the time AS6 is at a final release it wouldn’t surprise me if the performance is comparable to GlassFish.

  17. arjan says:

    Apart from the never ending discussion of starting with a full stack vs building the same thing yourself from the ground up, there is the fact that the Java EE 6 programming model is just awesome!

    I absolutely love it! 🙂

    The component based webframework, the scopes, the ORM mapper, the way transactions and concurrency are handled, it all comes together in a very nice and elegant way.

  18. Stg Unholy says:

    CDI is cool, but it cannot replace Spring, in case of DI…I did not find any way to inject Collections..f.ex: You have list of implementations of some kind and you want to choose implementation based on some input. With Spring it is easy, in CDI i did not find proper way to do it…

    1. Andy Gibson says:

      You can inject collections by returning them from a producer method :

      public List produceItems() {
      List results = ….;
      return results;

      This can be scoped to the application, the request or conversation.

      1. Hendy Irawan says:

        I guess that’s what he meant by CDI not having a way to inject collections.

        It’s really injecting an object that happens to be collection.

        In Spring there’s [list], [map], and [set]…

  19. Some Guy says:

    “Why doesn’t (JPA, JMA, JTA, EJB, JSF, CDI) work?”

    “JMA”… what is that?

    1. Lincoln says:

      Hahaha — Wooops! I was typing fast 😉

  20. iongion says:

    This would seem like a goose hitting Jupiter planet, but has any of you guys tried PHP/Python/Ruby with their web development frameworks/stacks ?

    Now, those are EASY stacks.

    You loose so much time setting things up in java world. I never understood this amount of pain.

    And except this, there is no joy in developing, .net, java … i always got the feeling when working with these that we become coding machines.

    1. Jason Porter says:

      I came from a PHP background, and I have done some rails stuff, yeah it’s fun and it’s easy and it works really nicely for smallish web pages (not web apps).

      When you start seeing big apps that need long transactions, messaging, interop with other technologies they tend to break down relatively quickly.

      On the PHP side it’s *very* easy to write a poor site. I always dread looking at someone’s PHP code. SQL plastered everywhere, logic in the view, gotchas with include, the list goes on and on.

      Like Lincoln and others have said though, do what works for what you need. If you just need to serve up some web pages, sure Java is probably overkill. As soon as you get into an application it’s probably easier to go with a language that has some of these things already figured out and integrated.

      1. wasser says:

        I am pretty sure that there can be crappy java code as there is php code.

        Nothing prevents you to plaster SQL code in Java programs.

        I don’t agree with the apps versus web pages.
        What is Facebook(php based+erlang)? An app or smallish web page group?

        PHP is damn easy to deploy, i think this is unmatched by any other (with moderate spread,erlang might offer other unmatched deployment features) web technology there.

        I too feel using java(the language+the tools) is no joy to develop, so many technologies invented to abstract the HTTP in somewhat way, when it should have remained what it is and used completely and properly.

        Although i am sure the quality of the java vm is a proven thing and i pretty much put much faith in new kids, jruby, groovy and scala.

        But this article, although enjoyable, shows me a pure java debate made of acronyms that i suppose, sound like incantations.

    2. henk says:

      ” has any of you guys tried PHP/Python/Ruby with their web development frameworks/stacks ?

      Now, those are EASY stacks.”

      Yeah, really easy… reaaallly easy…

      Until you try to propagate transactions across method calls. Until you want to have those separate methods that otherwise execute within the context of a larger transaction, be callable on their own too and expect them to be transactional as well… then it’s no so easy anymore. In Java EE this is absolutely trivial.

      When you have a 3 page web site for Joe’s Burgers from around the corner, PHP is indeed pretty easy (but honestly, so is plain JSP in that situation). If you need anything more, professional tools are simply a valuable asset.

      Because of people like you, IT is made the laughing stock of the engineering industry. Do you think that people in civil engineering only use a hammer when they need to build anything more complex than a shed? They simply use the modern & professional tools that are available and up to that job. Yet it IT, there is a group of people that insists that we should restrict ourselves to the basic tools, even when the majority of the software build today is not so basic.

      Java EE is such a professional tool, although one that really scales to basic applications too (but granted, if all you need is that 3 page website for Joe, than PHP or plain Tomcat will work just as well).

      1. iongion says:

        You must be kidding, i can create/execute transactional processes in no time in PHP also, and as wasser says, is facebook an average joe’s site also ?

      2. Paul youngh says:


        Nobody seems to be kidding here. Learn your facts, php is nothing more than what JSP is for Java. It doesn’t have anything like declarative transactions or JTA. You can only do transactions by passing connections around, which is cumbersome and error prone.

    3. Phil says:

      Former PHP guy here moving on to (back to) Java. Yes PHP is super easy but I’ve finally had to admit that when a project crosses too many lines/technologies it can become cumbersome and ugly. I’d say the setup time for JEE 6 at least isn’t that bad. I’d have pretty much strayed away from anything maybe pre 6 and for sure pre 5. I’m still learning so my clumsiness is what slows me down. But looking back after each sample project start its just not that bad. In fact now I think I prefer setting up a JEE 6 project to a Zend Framework project.

      I’m also finding that I’m writing much cleaner and organized code with Java. Yes its very possible to do with PHP and I hate when people swear that you can’t. But I am having to do less thinking about how to do it with Java.

      Now where I find the benefit of PHP/Rails etc is in hosting. The only worthwhile Java hosting I’ve found for the smaller contract projects I work on or my own ideas is Google app engine and so far writing for that almost negates all the fun of JEE 6. I spend alot of time on the “will it play” page trying to piece together what I need. I feel just like the example in this article about using Tomcat and then trying to add everything else on. If Oracle would put some focus on making Java friendly for the low end…let me rephrase that. They BETTER work on the low end before Microsoft beats them with .Net from the bottom up. .Net MVC is enticing as a rather easy framework to use (especially relative to WebForms) and theres plenty of low end cheap hosting to get projects up.

      1. henk says:

        You’re right that there are very little to no hosting options for the extremely low-end market where it concerns Java EE.

        Apparently, there isn’t really a market for that. Even small startup companies can typically afford to rent their own virtual server on which JBoss AS or Glassfish can be easily installed. Amazon EC makes this even easier and cheaper than traditional hosting companies have been able to do.

        For plain Servlet/JSP kind of apps, GAE is a really neat solution. I think this is even way better than PHP’s massive amount of shared hosting options. Don’t forget that PHP shared hosting always costs some amount of money and some sort of contract, while you are still fairly limited in what you’re able to do. You’re stuck with the settings your hoster has decided for you and left at the mercy of how well applications of other customers behave.

        It’s indeed a petty that GAE doesn’t offer more of the Java EE platform. I understand several of the restrictions (in broad lines, EJB imposes similar restrictions), but it still is a petty they just don’t support the EJB (lite) API. They do however support JPA and an amazing amount of existing frameworks actually does work on GAE or can be made to work on it.

        I agree it’s all a little experimental, finding out what works and what does not work, so this may not be the most attractive option for low-end users. Then again, low-end users might not care about fancy third party frameworks at all and for them what Google offers by default might just be enough.

  21. Bubak says:

    Haha, I have desktop app with embedded Spring and OpenJPA. I would really like to see how we could benefit from full J2EE container.

    1. Lincoln says:

      This discussion may not apply to you 😉 though you could use Embedded CDI (Weld) and Hibernate (JPA) to accomplish the same things.

      1. Jason says:

        A bit late joining this discussion. However, as you implied, you can use most of (never found one I could not) the JavaEE APIs outside of a container.

        I often use OpenEJB, OpenJPA ActiveMQ and so on with absolutly no issues at all.

        In fact, I often use those for Unit Testing, Database Testing and Integration Testing before deploying to the list of Application Servers “Officially” supported by the various applications I develop.

        I also use Spring/Hibernate and so on a lot.

        For many people it is simply a matter of style and personal preference.

        Most applications I architect, the technology frameworks are easily swapped. The classes I specify for instance are Services. The services can be assembled as Spring Beans, or EJB3, it frankly makes little difference to how the code is developed or organised.

        JavaEE is a huge step forward for the platform, and yes this was playing catch up.

        The objections most people have to JavaEE are actually objections to J2EE and the horible monster that was EJB 2.x

        On a side note, people who say Maven is the answer to Jar hell, obviously don’t know much about classloaders and the simple fact that the classpath is a flat namespace.

        The key to avoiding Jar hell is to use OSGi in conjunction with Maven. That way you get compiletime and runtime isolation.

        Anyone who says classloaders are not an issue has obviously never used a framework like Commons Logging.

  22. Kenneth says:

    Completely agree with you.
    People use to have think “Tomcat = lightweight” and “JEE = heavyweight” but never give it a try.
    We’ve been using JEE5 (and now JEE6) for our mainstream development and we never look back. We always think why to spend our time to assemble different parts when there is already a solid integrated solution.

    1. Paul youngh says:

      Indeed, I totally agree with that.

      If you actually try it you’ll notice the programming model is very lightweight indeed. No tons of XML to maintain and no need to do stuff like transactions or web components with cumbersome code of your own.

      Java EE 5 was a major step in the right direction, and Java EE 6 massively improves on it, particularly where it concerns the integration. You rarely have to be aware of using EJB, CDI or JTA. You just use beans with some annotations and you get powerful services in return.

      1. Bubak says:

        I think it does, it just proves that J2EE is not that flexible.

      2. arjan says:

        Budak, what are you talking about?

        J2EE indeed wasn’t that flexible, but Java EE (the topic of this article) is extremely flexible. In the web layer alone pretty much anything you think of can be decorated or replaced. This theme is spreading to other parts of Java EE.

        Furthermore, you can very easily disable what you don’t need, if it REALLY bothers you that all that power is there. JBoss AS 5 already comes with 4 configurations and you can easily configure your own one. Don’t want the Servlet container? A few rm commands and gone it is. Try that on Tomcat.

        Furthermore, Java EE 6 has officially introduced the concept of profiles to the platform. Configurations such as in JBoss AS and other implementations are just for yourself, to create your own personal stack. With profiles however a number of such configurations is standardized, so you can be sure a Java EE web profile app runs everywhere where this profile is supported.

        And if you really want, you can still run Spring, Wicket, PLAY! or whatever on Java EE and still be able to use a lot if not all of the services Java EE offers as a platform.

        You can accuse Java EE of many things perhaps, but not of it being inflexible.

  23. giri says:

    Since you said about documentation I am prompted to add this.
    The complexity of JEE and the other three letter acronyms sound so complex primarily because the integration points are not clearly documented.
    As some one commented above try porting the app from JBOSS 4 to 5. Not only it is poorly documented but each of the changes we need to experiment with before successful execution.
    The configuration between JEE – so called app servers need to be stndardised as well.
    Worst of these is lack of documentation on version compatibility of various components.

    I suggest to have a single budle installation of all these without the three letter names as a single product with a decent IDE will make JEE popular.

    Like in erstwhile delphi IDE, you can be given a provision to see the underlying working code for those who call ourself geeks like me:-).

    1. Paul youngh says:

      Giri, in a way Java EE 6 is this single bundle you’re talking about. The tree letter acronyms are mainly for people who want to add say jpa separately to Tomcat.

      With any Java EE 6 implementation, you get the full bundle and can just start writing web pages with business logic behind them that use the DB via object mappings. Although it never hurts to know your tools more intimately, you don’t really have to know which part of your code uses which three letter acronym tech under the hood.

  24. Been working with both approaches, full blown app server and “super pimped” servlet container/app, for quite a few years now. Spring and/or full JEE stack. Like many others, I’ve been sufffering quite a lot from EJB and JSF complexity.

    I think recent JEEs simplification comes too late. Its reputation already is severly damaged, and I guess lots of people won’t give it another try soon.

    One thing that was (and still is) frequently annoying me with java based apps is the fact that you waste a lot of time due to redeployment PermGen OOMs. Sure, the faster the server starts, the less you suffer, but it still remains annoying. 😉

    Even though I still work a lot with java based apps – I’d choose grails in general.

    1. Paul youngh says:

      I agree with you that Java EE is rather late, but who cares whether there first was a version that didn’t work as well? The point is that it’s a great platform *now*. New programmers hardly know there is this past and will just use it. You, as an old-timer do remember this past and therefor don’t use it.

      In the end, what is the difference?

      Grails is pretty cool, and you obviously enjoy it. But what if I told you that it too just a past, namely tracks, which was by all accounts pretty bad. Would you suddenly stop enjoying grails because tracks was so horrific?

      Doesn’t all that matter is that grails works *now*?

      1. Not quite.

        Old-timers teach new programmers. And I guess there are quite a lot of them teaching “Don’t use the full blown JEE stack, it’s far too complex and overkill”.

      2. Tim Jansen says:

        All the “old” stuff is still in JEE 6, it’s not even deprecated. You’d have to work in a complete vacuum to avoid it. Otherwise you will sooner or later encounter it because of some developer found some old function in the API and just used it without knowing the new way, or because you are using library or component that has not been completely ported.

      3. henk says:

        “Old-timers teach new programmers. And I guess there are quite a lot of them teaching “Don’t use the full blown JEE stack, it’s far too complex and overkill”.”

        It’s true that old-timers do teach new programmers, but there is a limit to that. If there wasn’t, we would still all be using Cobal and perhaps C for everything.

        New, younger programmers bring with them an influx of new ideas and they take the opportunity to start a new project with the new technology they love.

        When I just started to work as a developer, objects were still in their infancy and the old-timers of the day were trying to teach me that objects were overkill and unnecessary for anything but the largest software systems. Guess what, when the opportunity came me and the other programmers of my generation used objects anyway. We were faster with it and created better and more maintainable software than the dinosaurs who still tried to resist to objects. Eventually when the entire development effort migrated to OO, these old guys just lost and were fired.

        So go ahead, be that dinosaur. Let the new generation of (intelligent) programmers who are still fairly unbiased choose and embrace Java EE.

        I see this happening all around me. Young, eager, developers who just start new apps using Java EE and get their work done in no time. There is really nothing complex about it. There’s a single @Stateless annotation and your bean is transactional. A single other annotation and you have an entity manager. Where’s the complexity there? Let me spell it out for you; it isn’t there.

        Basically you’ll only succeed in making a fool out of yourself. Go ahead, tell your young developers how incredibly complex Java EE is. They’ll only laugh at you once they find out for themselves how simple and logic it all really is and start looking down on you because obviously such a ‘senile old fool’ is unable to grasp something that simple.

      4. @henk:

        Don’t get me wrong. I don’t teach “Don’t use the full blown JEE stack …”. I’d teach “Check available choices/skills and use whatever addresses problem/boundary conditions best”. But I bet there are a lots of old-timers advising not to use the full blown JEE stack in general (based on their experience).

        Lets have a look at JSF as a part of JEE now:

        Regarding webapps, JEE (even v6) is far from beeing the “golden hammer” addressing each and every requirement. JSF now is now aware of ajax – welcome on board ! Pimped by seam or prettyfaces
        it “even” addresses SEO and bookmarkable URLs. Other frameworks have been addressing this for ages. JCP in general is just too slow to catch up with real “world requirements”.

        So double-check what really addresses your problem best. Grails was my answer in most of the cases regarding webapps.

  25. Mario Peshev says:

    IMO JEE is pain in the ass if you need a project small enough to run great with servlets logic over Tomcat. But if we really need JSF app with a few other enhancements, than I would never return back to Tomcat but use a JEE server (remember the time I needed 2 weeks to setup JSF project on Tomcat seeking for all the necessary libraries over Chinese websites and trackers).

    As for the JPA, you can decrease the pressure in JSE projects if you use either Eclipse or Netbeans. For instance, the Eclipse + Web Tools Platform plugin uses Eclipse Dali, which creates full example on JPA + EclipseLink implementation and possibility to run on any container/server (even Derby/JavaDB integrated).

  26. Edwin Commandeur says:

    The best approach is probably, try out JEE versus a more lightweight stack and see what suits you.

    JEE6 is really new (JBoss 6 is still in milestone not in GA and the JEE6 spec got finalized last december) and it is interesting to see how much renewed interest in JEE it will generate.

    As far as the JEE versus Spring comparison: Spring contains so much stuff that helps you work with enterprise features that is not in JEE. It has simplified APIs and templates for working with JMS, JMX, JDBC, JNDI development etc. It abstracts data access exceptions into a common data access exception hierarchy, easing exception handling. It simplifies working with web services and so on.

  27. Eduardo Pelegri-Llopart says:

    Hi Lincoln, nice post.

    Re: JSPA — There is a legal reason for it. And, given all the recent noises on IP lawsuits in several IT industries, it seems to me that part has worked fairly well.

    There are a number of areas where the JCP can be improved, but some approaches that work very well for a foundation w/o any assets, like the ASF, do not necessarily work for standards that are the foundation for a multi-billion IT companies.

    IANAL and all of that 🙂

    – eduard/o

    1. Lincoln says:

      Thanks Eduardo –

      I agree with the intent of the JSPA, just not the implementation. I don’t think it should require physically mailing a document. Electronic signatures should be permitted. That’s my only gripe there — though, my other complaint is that it costs companies $5,000 to register.

      $5,000 is chump changes to Oracle, IBM, and the others. That’s how much money spills on the floor when they take a client out for drinks one night, but it prevents smaller companies (for whom $5,000 is more significant) from entering into the JCP.

      By making membership free and inviting donations, I’m sure *much* more funding could be procured. Companies like Oracle, IBM, and Red Hat will pour money in — but ask for a $5,000 / year barrier to entry, not donations, and you get just that. $5,000 / year.

      I know it’s already free for Individuals — but that’s not really the point. It should be free for everyone. Heck – I might even donate money if I thought good things were happening.

      Hence my Eclipse foundation remarks.

      PS. For those of you who are confused as to where this topic came from, I added some thoughts about the JCP to the end of the post.

  28. […] Choice of the week – 11/2010 Is Java EE 6 too complicated? […]

  29. Vince O'Sullivan says:

    Godammit! Why is it that the moment that I (almost) get my head around something (Cobol, PL/1, Visual Basic, Java, Groovy, CVS, Tomcat, etc.) it immediately becomes obsolete? No, it’s worse, I find that it became obsolete on the day I bought the book! How do they know?

    1. Lincoln says:

      Lol! Welcome to the software development industry…

      That is why technology is not important – in the end, technology is there to solve business problems, so it doesn’t matter what you choose as long as you get the job done.

  30. Gene De Lisa says:

    You won’t need an asbestos suit for this reply.

    Currently I’m using maven with jetty. I can launch jetty for each integration test via a plugin configed in my pom.xml

    Your linked (jsf 2) example doesn’t “run” anything from maven. You simply say something to the effect of now deploy to your server.

    I’d be much more convinced to give glassfish a try if I were able to launch it from my pom.

    See that wasn’t too flamey was it?

    1. Jason Porter says:

      There’s an embedded glassfish maven plugin: there’s a link there for the plugin page. Works pretty much the same as the jetty plugin.

    2. Lincoln says:

      And no, it wasn’t took flamey, thanks! (see my updated post — i had a few issues with the original instructions — aka, I made some typos 😉

  31. veggen says:

    Well, I am all for JEE. Spring’s ok, but I find the stateless in it’s core very unnatural and limiting. Anyway, JSF2, EJB 3.1, JPA2 etc. look like very good improvements, but CDI… well… CDI sucks. Compared to Seam 2’s bijection model, CDI looks incredibly complicated, way less powerful and overall shameful.

    1. Jason Porter says:

      A little more complicated, but not that much. What areas do you find it less powerful?

      1. veggen says:

        Well, being more complicated is a big deal. Maybe not to me personally, but it’s that argument that got Spring so popular over JEE. Anyway, I find it less powerful (or at least less wieldy) in many use-cases. One example that really got my attention it’s CDI’s apparent inability to provide a nullable scoped component. Whenever one requests a component, either a new one is created or an existing one is injected, but what if the logic allows for null? Seam had no problems with this. Of course, one can find a way around, but coupled with an annotation explosion and other boiler plate code that CDI requires (unlike Seam), it creates an environment where you often need to work around the framework instead of working with it.

      2. veggen says:

        And, another thing, CDI’s inability to work with nulls has another implication – there’s no way to manually remove an object from the scope. Seam had no problem with this, but in CDI it can certainly pose a limitation.

    2. Stuart Douglas says:

      The non-null requirement comes from the use of proxies, as it is impossible to proxy a null value. The reason why proxies are used instead of dynamic injection (like in seam 2) is due to the massive performance overhead associated with dynamic injection.

      I also do not think that there will be ‘Annotation Explosion’ as you have called it. I think that a large percentage of CDI beans will need no qualifiers and will not need any additional annotations, as there is only a single default impl.

      1. veggen says:

        I am just stating that CDI provides me with less power than Seam’s bijection did, without doubting the existence of some justification for that. Still, I’d always take the responsibility of carefully managing the overhead for more power from the framework in return.

  32. Ivan says:

    The facebook uses a lot of technologies.
    It has started from php but now it has to use a lot of different stuff including “painful” Java EE. (so disliked by “cowboy” coder “iongion” :). P.S. I suppose he has not participated in a really big project.

  33. Karim LITIM says:

    The problem is not in JEE but in its different implementations. Each JEE Server has its own “kitchen” anf if you want to deactivate “some JEE” faetures (like EJB) on WebSphere or WebLogic then forget it.

    Another problem related to JEE vendors is the JEE dummy Feature Pack that can, in some cases,forces you to spend money in order to use the “expensive feature implementation” (JPA2.0 on WebSphere)

    Onother one (not the last) is related to modularity. It is just not possible to replace an implementation with another (oh yeah, rely on classloading or some shared library ===> so portable 🙂

  34. Brian Knoblauch says:

    Definitely no flames from me! I’ve been saying this too. Use Tomcat if you can live with the limitations and you just have to use it. However, if you want things to work right, just install GlassFish and move on. There’s no need to fight with a partial platform when the “real deal” is readily available. You have to be in a seriously resource constrained environment to do otherwise…

  35. carlo says:

    I actually lead a JSF1.2 to JSF2.0 upgrade as part of a replatform.
    *EVERYTHING* broke. We spent literally weeks and weeks debugging every dropdown list.

    One guy we have (very smart) ended up with the "really hard" bugs. It took him three WEEKS to figure out what JSF was doing and what sequence it did it all in before he could properly fix the bugs.

    The idea an XML tweak is all you need to do to get from JSF1.2 to 2.0 is, in my opinion and based on real-wrold experience of an enterprise class app, purely fantasy.

Leave a Comment

Please note: In order to submit code or special characters, wrap it in

[code lang="xml"][/code]
(for your language) - or your tags will be eaten.

Please note: Comment moderation is enabled and may delay your comment from appearing. There is no need to resubmit your comment.