Well, I could tell people all day long why *I* love Spring, but I'll put just a few here. Hopefully you can identify with some of the following points.
- Spring helps you extricate the logic of configuration from your business logic. It encourages the clean separation of concerns you need to be able to
unit test code, inegrate it in one environment and then deploy it in any of numerous others, all without changing anything besides the configuration. Spring works in a public static void main(){} application, a lean web server like
Tomcat, Jetty, or tcServer, on a
Java EE application server or in environments like the cloud, all with just changes to the configuration, which Spring makes easy. Nothing else has this level of portability for even basic applications.
- Spring provides the powerful trinity of AOP, portable service abstractions and dependency injection, which everything else builds on. The rest of the Spring framework, Spring MVC, Spring Integration, Spring Batch, etc., all embrace these concepts to provide higher level solutions for specific types of problems in a consistent way, leveraging the same consistent concepts throughout. So, there's no magic, and any user is free to take advantage of these features from the lowest level support all the way to the specialized, abstract frameworks. This is a good example of the idea of "one kind of stuff" - everything in Spring is just a POJO. You don't have to care if it's any of the numerous EJB types in one place, a
servlet in another, a JCA connector in another, a
JSF managed bean, a
Struts action, etc. To Spring, it's all just POJOs that get adapted to those types of components. You can take advantage of services in the same way anywhere.
- Spring's the only platform built from the ground up with choice as a key feature. The mission statement, if you will, is portability and innovation in service of productivity. With Spring, you'll find clean integrations with numerous web frameworks, persistence frameworks (and indeed, numerous data base types beyond just RDBMSes!), integration and messaging middle-ware, cloud environments, etc.
- Spring tackles the tough problems. Java EE, for example, has featured an ever changing and increasingly backwards compatible solution for transactional data services that makes assumptions about the nature of the services that you can't change. It's also featured a low level API for messaging (JMS), a low level API for RDBMS-based data-access (
JDBC), and a very arcane model for third-party connectors to plugin to an otherwise top-heavy application server called JCA, Servlets, JSPs and JSF for web applications, JAXRPC, JAXRS, JAXWS, etc., for old-style
SOAP services, restful services, and document-oriented, contract-first SOAP services, etc. If you'r application fits in that mold, then great. Even there, Spring's got powerful solutions to help damatially simplify things (a consistent transaction API, no matter what the resource, the JdbcTemplate, the JmsTemplate, etc), but if you've got other problems to solve, then you're out of luck. Want to use Flex? Want to handle batch processes? Job scheduling? Caching? Systems integration? Use any of the dozens of other very powerful and very popular web frameworks, etc? Spring has options to help.
- Spring's an a la carte model. Be as heavy or as light as you like - the core framework works perfectly in a public static void main application with just two jars. You can add as you like.
- It's backwards compatible. The idea of a "standard" used to mean that users were insulated from volatile APIs and unportable features. However, to wit, huge chunks of EJB as introduced in Java EE 5, J2EE 1.4 and 1.3 have been deprecated, JAXRPC's deprecated, JSF 2 looks little like JSF 1, etc. Basically, if you bet on J2EE 8 years ago, you most certainly would have had to rewrite several parts of your app to track the latest updates. By comparison, a Spring bean as defined in Spring 1.0 would still work today if the doctype DTD declarations were replaced with the XSDs, *and* you'd have more options in the APIs, and for deployment scenarios, not less: Spring will work on those same J2EE 1.4 applications servers that Java EE 5 code won't ;-) To make things worse, the current crop of application servers are implementing 'profiles,' which not only don't require continued implementation of APIs previously supported, they remove entire chunks of the platform, effectively boxing you into an older version unless you switch to a different server (usually costy) that does continue to support the older technology.
- It's here, now. NoSQL/Big Data / the cloud are here now. So is Spring Data and Spring Hadoop, for example. Android is here, now. So is Spring Android. Java EE is by definition always behind the current trends. Parts of JavaEE 6 were started in 2005/6, and it's already been available for a year and a half. So the design of Java EE 6 is in some cases 5+ years old. Want cloud and big data support? Well, Java EE 7 is *supposed* to have some of it in late 2012... No mention of mobile support, however. Meanwhile, not all vendors (in fact, most have not) have shipped Java EE 6 implementations yet!
I hope this helps.
1
