n my 15 years as a software professional I've never seen a software stack as unproductivenot to mention as verbose or complicatedas J2EE, despite its enterprise-grade features. Every single J2EE project I have ever worked on ended the same way: me looking at long lines of Ant build scripts constantly rebuilding WARs and EARs (starting/stopping/re-deploying, and so on). No developer should spend half of his or her day waiting for even the simplest of code changes to be redeployed by an Ant script.
When my current company evaluated the future maintenance of our J2EE-based applications, it became clear that some of the core components needed a wholesale rewrite. Choosing Spring over Java EE 5 was an obvious choice (more on that later), but choosing the appropriate web container took a bit more time. After struggling with some of the "bugginess" of Eclipse WTP (especially when it comes to re-deploying project code into the web container), a simpler, leaner alternative emerged: using Spring with embedded Jetty.
Embedded Jetty Versus Standalone Web Containers
Jetty is widely recognized for its speed among Java web containers (mostly due to its NIO-based networking code), but the ability to start it in embedded mode has been one of its killer features for years. When you use Jetty in embedded mode you simply start it up from your regular main()
method and it just runs within the context of your application.
Using embedded Jetty also has a few huge productivity boosts, namely:
- It's very fast to start up (approx. one second on my dev box).
- Running it in debug mode enables hot code replacement, where the JVM instantly reloads any code you change in your Java classes (business components, servlets, etc.) or JSPs. Not a single second is wasted on redeploying WARs or EARs.
- It works in any standard Java IDE; there is no IDE or vendor lock-in.
The JVM's hot code replacement in particular has been a tremendous boost to our day-to-day productivity. I haven't seen a single Ant build in weeks. In those rare cases when I actually needed to restart the application (e.g., upon changing some Spring configuration), it took no more than 3-4 seconds.
Benefits of Spring Versus Java EE/J2EE
Often when Java EE 5 is compared with Spring, the focus is mostly on basic features such as dependency injection. But Spring is so much more than just that. In particular, its template classes are an amazing example of simplifying an API to maximize productivity. After discovering the Spring JdbcTemplate, which made working with raw JDBC so easy and fast, I lost all interest in developing a JPA model for our database. Spring also has many other template/helper classes, such as those for JMS or remoting (e.g., integrating the Hessian binary protocol into our application was a walk in the park).
Also, most of the best open-source Java libraries (such as Apache CXF or Apache Active MQ) now come with Spring integration out of the box. This gives you the flexibility to choose whichever best-of-breed components you need, instead of being stuck with the typical monolithic Java EE container's all-or-nothing approach.
Moreover, Spring sub-projects such as Spring Security or Spring BlazeDS are so far ahead of the Java EE stack's offerings (or have no equivalents in the stack at all), that anyone selecting Java EE as the basis for new application development really needs to reconsider that choice.