| > JBoss is NOT old-school and big honking (whatever that > means). The download size of JBoss is about 110MB, and it > starts in about a second. 10 seconds with an app that > contains hundreds to thousands of beans. > > Compare that to a typical Spring app, where the downloaded > size of all things you need easily exceeds 200MB and the war > itself is a 100MB or so. A war for Java EE is often some 1 to > 2MB for a BIG application. Go figure. I tried to steer clear of precise numbers, because they tend to change every couple of years... and you can easily date your knowledge by citing them. However, spin up a new Spring application today (there's an online project generator wizard at http://start.spring.io). Make it a web app, with Hibernate/JPA and the PostgreSQL database driver, and Spring Actuator for automated metrics. Build this generated app. The resulting executable JAR with all dependencies will weigh 24 megs, and that includes its app server. Ditch the Hibernate/JPA, and use PostgreSQL with Spring JDBC instead (which is often superior to an ORM anyway). Your total deliverable size drops to 13 megs. Look, it's all Java at the end of the day. Spring plays nice with JEE components, and in practice it's not necessarily such an either/or matter. The Java community has a sliding spectrum of bleeding-edge early adopters (e.g. Scala, Akka, Play)... conservative late-adopters (e.g. JEE)... and pragmatic moderates in between (e.g. Spring). If your comfort zone is on a different spot in the spectrum, or if you disagree with how someone else defines the spectrum, then by all means do your own thing. But the comment to which I replied said that, "There's very little reason to use Spring today". That, frankly, is nonsense. |
We all have our own preferences. I can guess what the "very little reason means". You hear this more often in Java (EE) discussions.
The thing is that in 2003/2004 Spring positioned itself as the necessary layer to make arcane Java EE APIs approachable and usable. With their FooBarTemplates Spring wraps everything that's wrappable, and at the time it made somewhat sense. Rod couldn't wrap EJB though, and as he deemed it "unfixable" he invented his own bean model to replace that.
At some point though Java EE started improving, and then started to improve a lot. Getting first class APIs such as JPA, co-designed by the Hibernate lead himself (Gavin King).
And what did Spring do? As a pavlov reaction they started wrapping again. But the JPA APIs were brand new, perfectly well designed, and didn't need wrapping. This was the basis of the fallout between Hibernate and Spring, and a revealing moment into how Spring operated. They weren't the benevolent dictator who out of the goodness of their hearts wanted to make life better for programmers, no, they just wanted you to depend on their APIs.
Rod later cashed big time, and Springsource, later pivotal became as commercial as the "evil" corporations they tried to wrap with their APIs.
Fast forward to Java EE 7, and Java EE has tons of perfectly fine APIs that don't need the Spring wrapping treatment. JMS, JPA, Bean Validation, CDI, EL, JAX-RS, ... NOTHING of that needs wrapping by Spring to make it usable. It's perfectly fine as-is.
So this is where the often heard "there's little reason to use Spring today" comes from, and I guess that is what was meant. Today Spring is just another platform. Java EE programmers don't need it to make their life better. Programmers in general can choose Java EE, or Spring, or .NET, or whatever.
If your preference is Spring, please, use it and be happy. It's not better than Java EE, but likely not much worse either. I've seen enough Spring code and Java EE code to say it's different, but still fairly equal.
I personally think the design process of Java EE is more open than that of Spring. Both are open source projects, and both have strong commercial influences as well as community influences, but with Java EE the design process is fully out in the open and people can comment on it and contribute. This is less the case with Spring. Yes, the source is open, but so is that of the Java EE RI and many other implementations. But Spring doesn't have an open design process, where Java EE has.