[brunoborges]

Luckily, the culture of over-engineering has shifted significantly thanks to modern approaches for designing Java-based systems.

The "Triple Crown" of Java frameworks, namely Spring Boot, Quarkus, and Micronaut, but also with the influence of smaller contenders (Dropwizard, Javalin, SparkJava, and a few others) have helped developers focus on business code rather 'design patterns' because these frameworks have embedded a lot of the "over-engineered" concepts into their 'opinionated' approaches.

Developers are no longer thinking too much about layers, and just writing components by following the guidelines and best practices of these frameworks. The final result is pretty similar among all of them, especially for microservices.

[acdha]

I like the sounds of that but I would definitely note that this requires _significant_ technical leadership. If you try to hire Java developers, 95% of the resumes you're going to get are people who learned Spring the bad way and have very little experience shipping efficient or reliable code.

[bottlerocketj]

Can I ask what you mean by learning Spring the bad way? I'm new to the industry and starting a Java role in Jan.

[acdha]

The general problem I’ve seen is complexity and action at a distance - basically many things where anyone trying to figure out how it works or make changes has to understand a lot of code in multiple places.

A mundane version of this problem is dependency management: every Spring app I know is constantly patching CVEs, almost always in optional code for features they aren’t even using, and sometimes upgrades are not trivial because you have to push around a lot of framework code. Node is similar but at least the tools are better.

None of that is specific to Spring, and I’m sure someone will pop up to say that’s doing it wrong but it’s been 100% of the work I’ve seen from multiple contractor teams so perhaps the way to characterize it is that the community doesn’t have enough culture of pushing back against support burden or complexity.

[stcroixx]

In my long time java shop we're doing pretty much the opposite - using less frameworks and libraries to minimize time spent on constant upgrades to the frameworks and their myriad dependencies for exposed vulnerabilities.