4 ms·
My complaint about spring is the same complaint I have about almost every runtime dependency injection framework. In the happy path everything just works. But w
by zaphar 4y ago
My complaint about spring is the same complaint I have about almost every runtime dependency injection framework. In the happy path everything just works. But when you get off that happy path which happens all the time in production for any system older than a month you get exceptions and those exceptions list stuff in the stack trace that you've never seen and didn't even know were being used. For those issues every once in a while when you try to dig into the error you find yourself deep into runtime reflection code somewhere trying to figure out how this particular configuration happened. How your code got glued together is a mass of difficult to read code buried deep in the spring framework.
We have a saying about these types of frameworks: They are a great way to turn compile errors into runtime errors.
When you are just starting out on a project it's great. You get up and running fast and as long as stuff doesn't change too much you are probably fine. But when your codebase reaches 5+ years of age it's highly likely to see a spike in "runtime errors" that potentially could have been compile time errors every time you release and releases get nerve wracking for a bit until eventually the codebase get's frozen in stone and someone starts suggesting we rewrite it.
- zaphar 4y agoI should mention that this isn't the fault of dependency injection itself. It's the natural result of doing that dependency injection at runtime using reflection. A better way is to use code generation so that you can actually see and reason about the code when something goes wrong.