Why i hate spring

At the beginning of my career, I really fell in love with Spring . I've been waiting for him for so long. I used it in all my projects. In addition, I even managed to shove a bunch of stuff from Spring Integration there . I was kind of king of XML. I made an RPC layer based on JMS, protobufs and Kaazing for our entire department and the bank as a whole. I thought, “This is so configurable. Just a couple of XML files are really flexible. ” I was very pleased with myself.

But some of my colleagues were inclined to disagree. They had problems when they tried to tie everything the way they wanted; they did not know where what xml files they needed. There were problems with versions of Spring, how to make friends with them (I, moreover, went far with modularity: we had 5 or 6 different modules with different version numbers, and it was impossible to just take and figure out which one to use without asking me). These were alarm bells, but I did not notice them; I thought I needed more documentation or that those guys were just stupid. This situation is typical in itself: the pleas of users of one of the most unloved and difficult to use frameworks for help often break about “yes there is one file and some parameters, it’s not so hard”, while everyone else is trying to find a magic combination of files and parameters to make something work somehow.

I still work in the same organization, but now I am a user of my old framework. As a result of this feeding of my dog's food, I began to hate Sam (the author means himself - approx. Lane. ) 2009-2010 for several reasons, but mostly - for Spring. Spring is evil in good weather, but when it is included in the library or API used by other programmers, this is another level of evil: like the fruit of love of Hitler and the devil. Don't let Spring stick out of your API.

Spring sucks for a number of reasons, and I felt that they need to be listed, because google has no clear counter arguments.
')

• Configuration in XML. I would like to think that we as a profession have left XML in the past. He is incredibly verbose, but it's flowers. Much more important is that I don't want to program in XML. Linking all classes together is an extremely important part of your application. You are a Java developer, not an XML developer. One of the delights of Java as a language is compile time safety . I can compile my applications that do not have Spring, and be 100% sure that everything is assembled, connected and ready to go. But if the application has Spring, you launch it, wait 30-60 seconds for it to initialize the bins before it falls. In today's world, this is crazy, especially if it is also multiplied by a bunch of integration tests in which you need to rotate the container this way and that. A separate place in the hit list deserves "this means that I can change the implementation without recompiling!". So no one does. Never.
  
  
• Magic. A replica usually follows: “Now you can do everything with the help of annotations! No more XML! ” It's great when you don't need to program in XML, but annotations are still magic. Until you start the application, you have no idea whether it will contact correctly. And even then you do not know whether it is properly connected; you just know that it is connected. I do not like magic.
  
  
• Importing other Spring files. At the moment, it infuriates me the most. I found that there is a tendency to break Spring-files into smaller ones and scatter them into modules. I just killed 2 weeks, crawling through the JARs and trying to find the right combination / order / version of the Spring files for something to work. Spring files in JARs are a bad, bad idea. Terrible. Every time you smear dependent Spring files on JARs, a child dies somewhere.
  
  
• Complexity. When you ask a candidate at an interview: “What are the pitfalls in Spring?” - most often you hear in response that he has a steep learning curve. True or not, this is a separate topic, but I would like to emphasize the fact that Spring is now so complex that it has its own framework - Spring Boot . Framework for framework. We are in “Framework Inception” - a film about Leonardo DiCaprio, who is trying to find his long-lost Java code, plunging deeper and deeper into the layers of XML and annotations before finally committing suicide.

The thing is, I'm sure: it is theoretically possible to use Spring successfully in an application. I have never seen anything like this before, and this is a problem. As for me, all the "buns" that he offers are quite possible without him. When we ask about Spring at the interview, the candidate usually answers: “With Spring, you have clean code, a division of responsibility, and it’s really good for testing.” In general, all those things I am a big fan of (especially testing), but in fact these are the results not of using Spring, but of good programming. Perhaps for Spring newbies, this is a good crutch for learning ideas such as dependency injection, mocking, and testing, but in fact they are orthogonal to Spring. If you use TDD, you will not have getters and setters in your code - only dependency injection through constructors, which you can “lock in” for testing, and then, when you tie your application together, you simply use the often forgotten way of creating objects - keyword "new". Often we create the class “ApplicationContext”, which is responsible for tying everything together. It is clean, everything is tested, I have compile time safety, and my tests run pretty darn fast.