The Decline Of Spring?


Wednesday, October 3rd, 2012 - By Vineet Sinha

I was recently talking to someone I respect very highly about the Spring Framework. I told him that that I would only very reluctantly consider it for a project.

Now, I have used Spring in the past, and am really a big fan of what they have done. But, these days, I keep thinking of ‘bloated’ in association with them, and wonder if their best days are perhaps behind them.

Bloatware?

My instinct is that the root of the problem is that SpringSource built a lot of great frameworks, and as they got adopted by developers put them under the simple banner of ‘Spring’. Perhaps Spring being an all-encompassing name for everything done by SpringSource is the problem. Yes, this must be a major ‘marketing win’, but as a developer it is hard to figure out where one part of Spring starts and where it ends.

For the most recent web based service that I was building, we considered using Netty, Jersey, Atmosphere, and Play Framework. Yes, those are really comparing apples and oranges, but examining these frameworks gave us a really good idea as to what was the best fit for our situation. When we decided we wanted to use something similar to Jersey, we spent a little time comparing it with others like RESTEasy. The thing is, we did not consider any of the Spring Frameworks.

The thing is that we realized that today we have so many open source frameworks that it would be very easy to get a lot of such 3rd-party code into our projects. And adding such frameworks would result in us needing to support and therefore understand the code. So instead of us using multiple large frameworks that do a lot but have various limitations we felt that it made the most sense to use the ‘best of breed’ for whatever we were including.

Framework Dependencies and Modularity

Now, we did get to a point where we wanted to add a couple of ‘social’ features, and we found that Spring Social looked to be one of the more interesting options. But adding it to our codebase meant that not only did we need to be careful in seeing how many of the other Spring Frameworks it dragged in, but that we also needed to seriously consider strategies to make sure that our entire code was insulated from the framework – so that an average developer did not need to know all the details of Spring.

I do want to add that I believe that the challenge here is really not modularity. The Spring Framework has done a great job here. The problem is that when using one particular framework from Spring, you end up needing to ‘adjust’ your usage because of the other frameworks.

Again, I do want to say that most of us on our team are comfortable with Spring. However, it is irresponsible of us as Software Engineers to add code that is not needed. We need our code to be maintainable at the end of the day.

But the fact that Spring has evolved into a set of inter-connected frameworks hurts me in using it. I would love to see Spring evolve into sharply defined frameworks.

Evolution…

The interesting thing is that the challenges in using Spring today are really part of what made Spring really good a few years ago. It really is a question of how fast Spring will evolve to the changing nature of Open Source Java Framework Ecosystem.

What gives me hope is that Spring’s growth was partly because of the bloatware in JavaEE. It was in large part the success of Spring that drove JavaEE to become more lightweight. Perhaps it will be the success of these open source frameworks that will drive Spring to focus on the strengths of the independent frameworks as opposed to the single mega-framework.

Update: Comments have been closed to prevent knee-jerk responses that do not address the issue. If you have a good response, please e-mail me (vineet at architexa dot com). If it does address the main point here, I will make sure it gets to be a top level blog post.

 

11 Comments

  1. Manuel says:

    Hi,

    I agree with you. Spring is so BIG that is not easy to know what you put into your project.

    It’s a great framework, but they should try to make easy selecting what you want to use.

  2. Bruce says:

    Can you provide more specific examples that support this statement:

    The problem is that when using one particular framework from Spring,
    you end up needing to ‘adjust’ your usage because of the other frameworks.

    We use two parts of Spring – dependency injection and Spring JDBC. The developers on our term understand those parts of Spring and have not had to learn or even be aware of the many other parts of Spring (Spring MVC, Spring Data, Spring Social, Spring AOP). That Spring has grown significantly hasn’t negatively effected our projects or our learning curve in using those two parts of Spring.

    If you do want to use the other parts of Spring in a project, say Spring Social, Spring MVC, Spring Data REST and Spring Data JPA there will be a learning curve and your project will need to use more Spring libraries. But Spring does provide excellent documentation and examples to assist developers learning those Spring libraries. Through the use of annotations and intelligent defaults the amount of code developers have to write to take advantage of the Spring libraries has been reduced.

    I don’t understand the negative results you allude are due to Spring’s growing number of libraries.

    • Vineet Sinha says:

      @Bruce, Glad you did not have this problem.

      With regards to specific examples, I did talk about Spring Social in the post but there have been other Spring Frameworks that we had this problem with.

      Another example was that in the same project above, we decided to use Rest/Jax-RS. The decision to use Spring or not was again very complicated.

      As for documentation, Spring projects do have documentation, but rarely are they better than the other frameworks. But, documentation is not my problem, though Documentation *needs* to be really high in Spring Frameworks, because they have their own way of doing things. And again, my problem is not growing number of libraries or frameworks. The challenge is that you can’t just choose one of the librarier.

      Let me put it this way, get a developer with no experience in Java coding and ask him to build a web app using Play Framework vs ‘the right Spring Framework’ – I can bet you good money that the Play Framework example will be up in almost 1/10th the time.

  3. jarrman says:

    I have also used spring in the past (when it was about 1.x version), and then there was no real choise. It was brilliant comparing to other frameworks (not to mention EJB 1.x which was disaster), at least in short lived applications. Now I prefer to use EJB 3.x and lean Java EE 6 Web Profile. Spring platform is very rich but unfortunatelly to big in my opinion. EJB & other technologies for lean JEE have 30-40% of possible configuration options of spring but they do not require such huge knowledge to be productive. Now I prefer to have 2-4 lean frameworks that have limited range of concepts and are independent and platform related bugs are easier to track and fix than in huge solutions. I really appreciate Spring and what it does to enterprise java but today there are more choises. In my opinion today J6EE is easier / faster to use and adapt (see Web Profile) than spring, especially on containers with excellent support (i.e. Glassfish 3.x). Of course if someone is good and productive in spring it may be equal productive as in pure J6EE. Recently I have observed many developers that do not know technology internals, they’re using copy / paste strategy for spring configuration because the area of technologies of spring is so vast that they can not undestands the elements of related technologies. This is bad practice. Spring uses JPA / Datasources / JNDI trying to do abstract layer but it also promotes lazines in knowledge of real technologies (how JPA works, how Persistence Unit is related to EntityManger etc.) someone using basic J6EE have more chances to realy understands what he does. That’s my opinion.

  4. Matthew says:

    Seems to me that you’re looking for Spring to be something that it isn’t. SpringSource has created a rich ecosystem of higher order frameworks based on each other. To me, that’s it’s primary feature. Sure, I could go out and pick the best of breed of each little thing I want to do, but then I have to understand 5 different programming philosophies and whole new sets of quirks and inter-operability issues.

    I understand Spring and it’s philosophy and I can do really great and productive things with it. Now I’m all for learning new frameworks, but I don’t have the luxury of changing which technologies and frameworks I use for each project. I too and building an ecosystem, as are many developers out there.

    So while I have no problem with you using a different approach to choosing your technologies, I think it’s disingenuous to suggest that SpringSource is doing something wrong by building an ecosystem just because you don’t want one. That’s a bit like complaining that your fork doesn’t cut as well as a knife. Just my $.02.

    • Vineet Sinha says:

      @Matthew, Great points.

      Assuming that ‘Spring Frameworks’ is supposed to be a set of frameworks that depend on each other – then they are being successful in doing it.

      However, this idea of having frameworks that depend on one another while important in the early days of Java, is not as relevant today – hence the expected decline. Perhaps they need to stop depending on one another.

      Yes, frameworks having quirks and inter-operability issues is true. But in my experience the Spring Frameworks are the only one in which these issues reach beyond the code that is calling it.

      Lastly, I am glad that they have built an ecosystem – I appreciate that. But having an ecosystem has nothing to do with having a complex set of framework dependencies.

  5. Anti-FUD says:

    Code-examples (with regards to your point about Spring Social) or it didn’t happen!