So, Rod Johnson is joining Typesafe. This means that Spring is going to be rewritten in Scala (viz Scaladoc for AbstractScalaCheckTransactionalFunctionalSpringSpecification); that SpringData is going to start using Slick core and that Spring Framework 3.2 is going to be the last one that will be officially supported on Web[Logic | Sphere]. On the Akka side, starting with 2.2, Akka is going to require WebLogic 12c to run.

Of course not
Nothing dramatic is going to happen to your favourite framework. Scala & Akka is not suddenly going to become infected with Spring’s Java-ness; nor does it mean that Spring Framework is going to drop support for the typical Java EE beasts lurking inside your favourite Java EE application server. In fact, I think that Spring Framework is going to send its feelers out into the Scala world, and allow Java programmers to start writing portions of their Spring applications in Scala.
If the adoption of Scala and Akka is the aim, then Rod Johnson joining Typesafe is definitely good news. He brings a name (and experience) that the target companies may recognise. Myself and the entire Cake Solutions team will have much easier position in recommending & introducing Scala and Akka at our consulting gigs, shamelessly using the argument from authority: “but Rod Johnson himself has joined Typesafe!”

Peoples of our planet must prohibit to Rod Johnson to push any commit to typesafe repository. Scala-around environment can not be defile by any spring “feature”. Stop the massacre otherwise typesafe will become a huge bigleton defined in application context dot xml!
Ah, don’t worry. In swift and deadly retaliation, the Scala community would add the AbstractCakeBeanFactorySupport and the implementations AnnotatedCakeBeanFactory and ScalaConfigCakeBeanFactory.
Though bigleton is good–is it a bit like pool of singletons
I remember Spring as a “savior” framework in dark ages of EJB 2. Spring at that time was something that simplified J2EE development A LOT. Of course you could shoot your foot as it often was case when you used it wrong. Unfortunately for Spring world found out that J2EE is not fancy and they dropped 2 from name and some other places to make it usable.
Still for me Spring was revolution when appeared.
I never really had to suffer EJBs in anger. But for me, too, Spring was a revelation. It finally allowed me to stop worrying about instances, to focus on the critical functionality and to compose that functionality easily… It was the first approach that rewarded good design. Recall that before Spring, if you really wanted to sharply define small components in your code—a good thing—you ended up with lots of pain in instantiating the application. Throw in code that takes care of the common JEE tasks: data access, transactions, JMS, et cetera, it was (and is) a pleasure to use it.
Looking back, I started with Spring in version 0.something, and went along the journey through the XMLs, then annotations, Java config, …; and now Spring Integration, Spring Data and so many others. There is some brilliant engineering in the Spring codebase, and I cannot say that Spring is obsolete, irrelevant or unnecessary. I just have a huge ‘well done’ to the entire Spring Portfolio team.
But it’s not all over. Hang on for just a few days for SpringOne 2GX, there’ll be more exciting Spring news.
Pingback: This week in #Scala (05/10/2012) | Cake Solutions Team Blog
I remember writing EJBs. It was impossible to do it in any way other than in anger. Local and remote interfaces, XML configuration files; it really was very awkward and detracted from the functionality you were actually trying to implement. Spring made things a lot more straightforward and was rewarding to use as a result.
I hope you’re right Jan, and that it’s not all over for Spring. Even if it is time to move on, using Spring taught me a lot about software design that I’m sure will continue to be useful in the future.