| I like Spring, I find it makes Java development pleasant, plus I have unfair access to the Spring team members by working for the same company. So I'll bite. > Huge XML configuration files instead of code? Spring (mostly annotations now). Spring 3, yes. Spring 4 and 5, no. XML has not been the blessed configuration approach for ~4 years. > Stupid names like AbstractSingletonProxyFactoryBean? Spring. Java is a language that has evolved enormously in expressiveness since Spring began, meaning heavyweight Go4 patterns were necessary early on to maintain a flexible substrate with a uniform interface serving very many use cases? Spring. > That aside, on startup Spring will auto generate classes which really slows things down. I believed this urban legend too. Dave Syer, who is understandably interested in Spring criticism, has done more empirical investigation than anyone on this topic[0]. The tl;dr is that boot time is proportional to total classes loaded. That's all, that's it. In-memory reflection operations are hilariously, stupidly, insanely faster than I/O. The JVM fetches and loads classes individually. So if you have a lot of classes, it takes a longer time to load. The other thing to bear in mind is that Spring relies on this much less than it used to. As the language and JVM have evolved, so has Spring. > The underling code is full of maps to control request lifecycle ... Not real names but the idea and number of steps is. Are you talking about servlet filters? Because any web framework is going to have a few of these. Spring MVC adds a handful and all of them can be removed, replaced or added to. Spring Security adds a bunch and all of them can be removed, replaced or added to. But the defaults are chosen because of feedback, not just for the heck of it. > Add on top of this JPA which is super easy but quickly breaks down to a lot of DB calls. JPA is great for people who don't want to learn SQL and simple CRUD apps but anything with any amount of data will quickly slow down to thousands of DB round trips. In general, yes, I agree that JPA is a PITA. For a small to medium system I would try to avoid it where possible. For a sufficiently large codebase -- thousands of domain objects, dozens or hundreds of programmers -- it might be a necessary evil. Mind you, if you want to see a world where the database goes from abused to outright mocked and ignored, pay a visit to Rails land. It drives me batty. [0] https://github.com/dsyer/spring-boot-startup-bench, particularly https://github.com/dsyer/spring-boot-startup-bench/tree/mast... |
The biggest issue I have with spring isn't performance but is the huge internal state that is the basis of Spring's DI.
After a few versions you end up with code that depends on bean named 'Abd" to preform a task, but in the next version is renamed to "Abc" which fixes the typo, but makes all the documentation off. And the 3 other classes that also needed that task still look for it under the name "Abd". And then the next major version replaces this entire module and the bean name is now "Xyz". To me this IS spring programming. Googling the DI names and trying them one by until you get the desired run time functionality.
I've had apps in production with unused beans defined (It only had 1 function that only throw an exception and was never called) but had to be defined or something would break. Multiple team members wasted some free time trying to locate the code that was requiring that bean but nobody could ever figure it out. At some point everybody gave up, it was easier to just let it be.
Most developers have little to no idea what is actually going on inside their spring apps (or even what half their dependencies are). When a struts like vulnerability comes along in the spring world it is going to be a massive PITA to fix. With how complex this all is I have little doubt that a vulnerability exist somewhere in there.