So I've been working on a simple little Java web app as a learning tool for myself. The stack I'm using is Stripes 1.5.3 (a great little web framework that I'd like to package for Fedora), Spring 3.0.2, Hibernate 3.5.1 with Apache Derby in Tomcat 6. The reason I'm using this stack, rather than something like Glassfish or a JBoss 6 milestone, is for the express purpose to try out the new releases of Spring and Hibernate. The additional experience with the two frameworks is helpful as well. I'm actually using Hibernate as a JPA2 provider rather than native Hibernate.
Anyways, the refrain I've often heard about Spring is that it's "sooo much lighter weight than Java EE". Now, this was most assuredly true back in the dark days of EJB2 and J2EE 1.3/1.4. The world has since moved on to Java EE 6 which looks very spiffy and developer friendly with EJB 3.1, CDI and JPA. Back to Spring, from a developer's point of view, managing the 31 jars I needed just to get a single crud page working is a little involved and practically all of it came from Spring's dependencies. I needed 10 separate org.springframework jars plus their dependencies for a relatively trivial web application. The winner was of course the esoteric error messages explaining to me why it couldn't autowire something (missing configuration item for the transaction handling, which led to missing jar dependency to enable that feature). That Java EE App Server that bundles all the stuff I need? Yes please!
P.S. Yes, I know of Maven, but I wanted to keep the scope creep to a minimum for this project.
Yes, Spring went from lightweight to XML hell to JAR hell
ReplyDeleteThis is just bad faith guys. What you call weight, I call it modularity and freedom of choice. Now of course, with great power comes great responsibility ;o)
ReplyDeleteNow the funny part is that Glassfish actually enables such modularity thanks to integration of OSGi and so on. But like it or not, Spring was also the first one to move in there with dynamic modules.
The truth is that when it comes to fast-paced and bold innovation, Spring (or any non-committee standard for that matter) will always be ahead.
"fast-paced", hum... bot sure anymore (Spring Web Flow still doesn't do JSF 2.0, Spring 3.0 doesn't do CDI, and it took a while for Spring to use annotation), and plenty of corporations don't always need fast pace (I still have customers doing JDK 1.4). Innovation ? Not sure either. It use to (Spring Batch is great) but it doesn't any more (REST implementation arrived late without doing JAX-RS, Spring Web Flow got inspired by Seam, have you tried Spring WS ? a nightmare....).
ReplyDeleteNo mater how many smart brains there are at SpringSource (and yes, these guys are clever), Java EE has many brains around the table and have (finally) created a great modular specification to work with.
provided is what I like ;o)
hmmm, haven't heard from S2 about OSGi in a loooong time
ReplyDeleteIf you measure innovation by how much and how fast they implement JEE specs, then maybe not. But since they don't wait for JEE specs to be released and come up with alternate and sometimes better solutions/integrations with existing technologies, this criterion is not very valuable to me. They do GWT integration in a big way, and they worked well with Adobe for Spring BlazeDS integration. I've actually tried Spring WS and it works great for me. So do CXF and tons of other frameworks I choose depending on the environment and the constraints of the project at hand.
ReplyDeleteAs for annotations, they have been available for quite some time already, longer than the time I've used them since I was perfectly OK with the non-intrusiveness of XML, especially with namespace handlers to minimize the verbosity of it. Plus they have the option to configure the whole environment through Java (Spring Configuration).
Now I don't want to sound like I'm saying JEE6 is bad tech. Quite the contrary actually. But there is one design flaw according to my standards: there were far too many application server vendors involved in the design of JEE in the past, which led us to Weblogic, Websphere and all this vendor lock-in hell. Now I don't know how it will evolve in the future since we haven't seen any mainstream implementation yet (Weblogic and Websphere that is) and what it will mean in terms of development and deployment time wasted. In the meantime, I'm quite happy with the way Spring allows me to build my products as WARs, deploy them to my Tomcat server, and move on with it. If the next version of Weblogic allows me to do that (which implies Oracle selling less consulting time...), then we'll call it even.
May I add that one of the main reasons why you and I still have customers stuck with JDK 1.4 and EJB2 is because "provided" also made it very difficult and expensive for them to upgrade and follow up on innovation. And look where we are now. Amongst customers willing to upgrade to JEE6, most of them are waiting for their application server provider to upgrade, hoping that it won't cost them too much in the process, otherwise they will just remain stuck with old stuff because they were told on the golf course that there is no alternative. As developers, I think we should promote technologies that allow our customers to save money on deployment platforms and put more of that money into development itself and pushing innovative and expressive technologies. Spring, Grails or Glassfish are excellent candidates for that, but unfortunately, JEE as a spec pushes more towards server vendors than towards actually building software on top of it. And the fact that Oracle is now in control of the JCP is not to reassure me.
ReplyDeleteWow! I was not expecting this many comments to my venting. Some interesting stuff to digest, but for now I stand by initial statement: It was way too much work getting this app started and the major culprit was Spring. The modularity is nice right up to the point where I need 8-15 jars to do anything useful.
ReplyDeleteBut why do you focus so much on the number of JAR's so much. Any JEE server brings many more JAR's into your classpath and just hides it to you in the same way as a good Maven configuration does with transitive dependencies. But when your development is done and you want to deploy your application to a JEE server, you'll see how painful it can be to have all these provided dependencies configured and not conflicting with your own stuff, not to mention the fact that the container forces certain versions on you.
ReplyDelete