Okay, maybe I spoke to strongly, it is very widely used and does have some nice ideas (Spring Boot is awesome). But it's just my opinion that Spring does give a lot of new devs the idea that Java is overly complex. And for me at least, I've only needed to use dependency injection once throughout my years as a dev (worked in many companies, large to small). Had to rename a class in a large microservice and didn't have to do a search and replace to rename all the places it was used.
But, in my opinion, the cons outweigh the benefits. It adds a lot of complexity for a feature that is rarely used. Am sure if used in a major refactor it'd be nice, but some search and replace is much better than adding an entire layer to your system that in many ways is not strongly typed (auto-wiring), and also adds an entire set of steps to the debugging process. Am actually pretty good at debugging Spring wiring problems, but still don't think you should have to have learned the art of Spring wiring just to debug something relatively simple - how your components are linked together - and all done at runtime.
To me, if tool builders want to support dependency injection, it should be done at the compiler level, along with the rest of the linking of objects. Yeah, don't think dynamically wiring objects is all that useful for a very large majority of builds...
... thought it over, I think I'd like this actually. A new, dedicated component type where the Java compiler checks your DI. That might be very nice. Yeah, also because having a component type will support using DI where it should be, at the component level, not on every class like it tends to be used.
