4 ms·

Spring has gotten so bloated. It seems like there's no feature request they can say "no" to. Plus there's multiple ways of doing the same thing. e.g. JPA,

Spring has gotten so bloated. It seems like there's no feature request they can say "no" to. Plus there's multiple ways of doing the same thing. e.g. JPA, spring-data. their call stacks between injected components are sometimes a couple dozen layers deep and it makes no sense. they don't provide easy upgrade paths between majors versions and they stop updating vulnerabilities on older major versions. I inherited some code that was using version x but had to be upgraded due to critical vulnerabilities. The vulns weren't fixed in x or y but only z. I tried moving over and their cryptic unit test fixtures stopped working. No docs on migration. Spring is sort of like cancer.

okeuro49 3y ago
It would be pretty unusual for Spring not to take advantage of virtual threads, given the potential for dramatic performance improvements under many workloads.
nforgerit 3y ago
> It seems like there's no feature request they can say "no" to. Well the opposite of this is the antiquated world of "old Java". My subjective assessment is that Spring is somewhere in the middle: reasonable conservatism of principles but eager adoption of beneficial new things. Jumping on virtual threads is a reasonable action. > their call stacks between injected components are sometimes a couple dozen layers deep and it makes no sense. We're talking big enterprise-y software, right? Things get huge over time, no way out of complexity. The major red-flag would be accidental complexity which Spring, compared to the rest of the Java world, generally manages well, I'd say. > they don't provide easy upgrade paths between majors versions and they stop updating vulnerabilities on older major versions. I inherited some code that was using version x but had to be upgraded due to critical vulnerabilities. The vulns weren't fixed in x or y but only z. I tried moving over and their cryptic unit test fixtures stopped working. No docs on migration. Spring is sort of like cancer. Well non-trivial upgrade paths is the essence of a "major version upgrade". The alternative is to let old ideas never die and either stop introducing new concepts at all (old Java) or introduce them and make the framework bloated (something you criticized in the beginning of your comment). It's a trade-off which I think generally is well managed in Spring. It's boring, but in a good way.
microflash 3y ago
> Spring has gotten so bloated. I'd call Spring feature-rich than bloated. You can always shed weight that you don't want to carry. > Plus there's multiple ways of doing the same thing. e.g. JPA, spring-data. That's because there are different ways to solve a problem. Someone may want an ORM-based approach to connect to the database; they can choose spring-data-jpa. Someone may want to use JDBC with a light abstraction on top of it; they can choose spring-data-jdbc. It's all about choices and right tradeoffs and Spring offers plenty of them. > they don't provide easy upgrade paths between majors versions That's not my experience. I've been happily upgrading 2.x.x versions and plan to upgrade to 3.2.x when it is ready. But depending on the codebase, I admit it can be painful. Projects like OpenRewrite[1] might help here. > and they stop updating vulnerabilities on older major versions. This is not news. They want you to pay for extended support if you need it. > No docs on migration. They do maintain migration docs on GitHub wiki which are a lot more detailed than their blog posts on migration. Here's the latest one to upgrade from Spring Boot 2 to 3: https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide https://github.com/spring-projects/spring-boot/wiki/Spring-B... [1]: https://github.com/openrewrite/rewrite https://github.com/openrewrite/rewrite
- Salgat 3y ago
  My biggest issue with "feature rich" is that unless you have strict control over your developers' usage (which won't happen in most large companies), you'll inevitably have all sorts of bloat used by various teams in your organization, which just adds to the cognitive overhead for anyone who needs to work on those services. You know the old adage: once you provide something in the API, you'll have to support it forever.
geodel 3y ago
> Spring is sort of like cancer. That itself is kind of polite way of putting it. This thing is freaking pandemic virus. Spreading in all sort of projects including code with single CRUD operation.

okeuro49 3y ago

It would be pretty unusual for Spring not to take advantage of virtual threads, given the potential for dramatic performance improvements under many workloads.

nforgerit 3y ago

> It seems like there's no feature request they can say "no" to. Well the opposite of this is the antiquated world of "old Java". My subjective assessment is that Spring is somewhere in the middle: reasonable conservatism of principles but eager adoption of beneficial new things. Jumping on virtual threads is a reasonable action. > their call stacks between injected components are sometimes a couple dozen layers deep and it makes no sense. We're talking big enterprise-y software, right? Things get huge over time, no way out of complexity. The major red-flag would be accidental complexity which Spring, compared to the rest of the Java world, generally manages well, I'd say. > they don't provide easy upgrade paths between majors versions and they stop updating vulnerabilities on older major versions. I inherited some code that was using version x but had to be upgraded due to critical vulnerabilities. The vulns weren't fixed in x or y but only z. I tried moving over and their cryptic unit test fixtures stopped working. No docs on migration. Spring is sort of like cancer. Well non-trivial upgrade paths is the essence of a "major version upgrade". The alternative is to let old ideas never die and either stop introducing new concepts at all (old Java) or introduce them and make the framework bloated (something you criticized in the beginning of your comment). It's a trade-off which I think generally is well managed in Spring. It's boring, but in a good way.

microflash 3y ago

> Spring has gotten so bloated. I'd call Spring feature-rich than bloated. You can always shed weight that you don't want to carry. > Plus there's multiple ways of doing the same thing. e.g. JPA, spring-data. That's because there are different ways to solve a problem. Someone may want an ORM-based approach to connect to the database; they can choose spring-data-jpa. Someone may want to use JDBC with a light abstraction on top of it; they can choose spring-data-jdbc. It's all about choices and right tradeoffs and Spring offers plenty of them. > they don't provide easy upgrade paths between majors versions That's not my experience. I've been happily upgrading 2.x.x versions and plan to upgrade to 3.2.x when it is ready. But depending on the codebase, I admit it can be painful. Projects like OpenRewrite[1] might help here. > and they stop updating vulnerabilities on older major versions. This is not news. They want you to pay for extended support if you need it. > No docs on migration. They do maintain migration docs on GitHub wiki which are a lot more detailed than their blog posts on migration. Here's the latest one to upgrade from Spring Boot 2 to 3: https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide https://github.com/spring-projects/spring-boot/wiki/Spring-B... [1]: https://github.com/openrewrite/rewrite https://github.com/openrewrite/rewrite

Salgat 3y ago
My biggest issue with "feature rich" is that unless you have strict control over your developers' usage (which won't happen in most large companies), you'll inevitably have all sorts of bloat used by various teams in your organization, which just adds to the cognitive overhead for anyone who needs to work on those services. You know the old adage: once you provide something in the API, you'll have to support it forever.

geodel 3y ago

> Spring is sort of like cancer. That itself is kind of polite way of putting it. This thing is freaking pandemic virus. Spreading in all sort of projects including code with single CRUD operation.