11 ms·

Spring 6.1 now compatible with virtual threads and JDK 21

154 points by philonoist 3y ago

deleted 3y ago
[deleted]
fnord77 3y ago
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.
xyst 3y ago
All of these nice features of the JDK yet most Fortune 500 companies probably still using JDK8 or 9.
- volkadav 3y ago
  With extended support available for JDK 8 until this end of this decade or so, it's going to be a while before the real laggards upgrade, heh. Maybe that'll be my generation's method of funding the retirement RV purchase like the COBOL grognards circa y2k, haha.
- ebiester 3y ago
  Who's using JDK 9? I understand the JDK 8 bit - the breaking changes in large code bases are a big lift, especially in projects with no significant changes for years. However, if you're on 9, the lift is much lower and primarily on QE. Why stay on 9?
  - sverhagen 3y ago
    For large organizations it's also an organizational lift, plus their attraction to have all the latest goodies from the latest JVM versions is probably a little less, so a lot of the same inertia that existing in moving from 7 to 8 and from 8 to 9 is going to resurface for any migration, even if the actual breakages during the compilation step are less.
- carimura 3y ago
  Most companies I talk to have a mixture of 8 for many stable unchanging applications and [11, 17, latest] for newer stuff.
- invalidname 3y ago
  That's because most of them haven't "really" migrated to containers. Once this is done the process of using a newer version of Java will become seamless.
  - jjtheblunt 3y ago
oblio 3y ago
Somewhat off-topic, somewhat related: Is Hibernate moving towards Java generics, about 2 decades after the fact? Spring seems much bigger and seems to moving much more quickly, but it's weird that Hibernate seems to still be stuck somewhere around Java-in-the-00s.
- krzyk 3y ago
  Hibernate is probably held back by JPA, which evolves slower than Java itself.
- invalidname 3y ago
  There are things they can't do due to erasure but they use generics quite a bit in the API. Spring Boot uses generics for the CRUD interfaces etc.
- debug-desperado 3y ago
  It has supported generic List and Set interfaces for one-to-many and many-to-many mappings since Hibernate 3 I believe (~2005). What did you have in mind?
kitanata 3y ago
[flagged]
greatpostman 3y ago
I keep reading negativity about spring. I got curious, am building the backend for a new startup with spring boot 3. It’s been a breeze. Everything works, great tooling, very mature software. Am I missing something? Will I regret this in six months?
- matwood 3y ago
  No. Lots of spring hate is from a decade+ ago. Spring boot plus jOOQ is a very productive backend.
  - thegaulofthem 3y ago
    Spring of a decade plus ago was fine, it just required a day or two of upstart to configure the whole deal if you weren’t already familiar and had a good project to reference as a basis for bootstrapping. The tradeoff of today with Spring Boot is you might get bitten down the line with a little configuration mystery, although it’s such a well-blazed path you’re probably in good company and will find your error solved and documented. In addition, it’s Java so virtually any serious task is done in a well-blazed fashion with numerous open-source options available. In contrast my Node library I used to generate and validate an XML document at work last month cannot read in its own XML output. It’s a boon for efficiency. The only downside Java really has is that it’s a bit harder to “hack on” a dynamic, evolving JSON structure so it may be a bad fit for organizational reasons if your company lacks a cohesive, mature Engineering staff.
    - chasd00 3y ago
      my biggest gripe with old Spring was how far you had to go to get "hello world" on the browser when starting from zero. I never would have thought embedding the whole application server would be a good idea but SpringBoot proved me wrong. That plus the annotation based config vs xml files is what made fast development with Spring possible (in my mind). Also, Spring would be a miserable experience if it were not for Maven/Gradle. Have you ever counted the jar files included in a typical SpringBoot+Spring-Security+Spring-Data app?
nobleach 3y ago
So far the responses have been lukewarm to negative. I'm all for a framework as big as Spring, blazing the trail to use Virtual Threads! I haven't used Spring Boot in a few years, and Webflux was a paradigm shift that didn't interest me. It'd be nice to see what this does for the framework.
- hashmash 3y ago
  Where can we read about the responses?
  - nobleach 3y ago
    sorry, I meant the 8 comments here on HN. (there are quite a few more now)
nprateem 3y ago
I just wish there was an admin generator like django's
wiseowise 3y ago
How’s performance? Is it better? Any benchmarks?
pylua 3y ago
I wonder if there will be any tools to detect pinning or synchronized use to help with the virtual threads transition. Blockhound I have gound useful for detecting blocking in non blocking areas.
- mping 3y ago
  There is a flag you can pass to the JVM to emit a log when a thread is pinned. It can also log a stack trace to show the call stack.
vkaku 3y ago
Moving the needle. But still as bloated as it can get. Never was invested in anything beyond Java SE, now I'm never going to invest in Java SE again.

154 points by philonoist 3y ago

deleted 3y ago

[deleted]

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.

xyst 3y ago

All of these nice features of the JDK yet most Fortune 500 companies probably still using JDK8 or 9.

volkadav 3y ago
With extended support available for JDK 8 until this end of this decade or so, it's going to be a while before the real laggards upgrade, heh. Maybe that'll be my generation's method of funding the retirement RV purchase like the COBOL grognards circa y2k, haha.
ebiester 3y ago
Who's using JDK 9? I understand the JDK 8 bit - the breaking changes in large code bases are a big lift, especially in projects with no significant changes for years. However, if you're on 9, the lift is much lower and primarily on QE. Why stay on 9?
- sverhagen 3y ago
  For large organizations it's also an organizational lift, plus their attraction to have all the latest goodies from the latest JVM versions is probably a little less, so a lot of the same inertia that existing in moving from 7 to 8 and from 8 to 9 is going to resurface for any migration, even if the actual breakages during the compilation step are less.
carimura 3y ago
Most companies I talk to have a mixture of 8 for many stable unchanging applications and [11, 17, latest] for newer stuff.
invalidname 3y ago
That's because most of them haven't "really" migrated to containers. Once this is done the process of using a newer version of Java will become seamless.
- jjtheblunt 3y ago

oblio 3y ago

Somewhat off-topic, somewhat related: Is Hibernate moving towards Java generics, about 2 decades after the fact? Spring seems much bigger and seems to moving much more quickly, but it's weird that Hibernate seems to still be stuck somewhere around Java-in-the-00s.

krzyk 3y ago
Hibernate is probably held back by JPA, which evolves slower than Java itself.
invalidname 3y ago
There are things they can't do due to erasure but they use generics quite a bit in the API. Spring Boot uses generics for the CRUD interfaces etc.
debug-desperado 3y ago
It has supported generic List and Set interfaces for one-to-many and many-to-many mappings since Hibernate 3 I believe (~2005). What did you have in mind?

kitanata 3y ago

[flagged]

greatpostman 3y ago

I keep reading negativity about spring. I got curious, am building the backend for a new startup with spring boot 3. It’s been a breeze. Everything works, great tooling, very mature software. Am I missing something? Will I regret this in six months?

matwood 3y ago
No. Lots of spring hate is from a decade+ ago. Spring boot plus jOOQ is a very productive backend.
- thegaulofthem 3y ago
  Spring of a decade plus ago was fine, it just required a day or two of upstart to configure the whole deal if you weren’t already familiar and had a good project to reference as a basis for bootstrapping. The tradeoff of today with Spring Boot is you might get bitten down the line with a little configuration mystery, although it’s such a well-blazed path you’re probably in good company and will find your error solved and documented. In addition, it’s Java so virtually any serious task is done in a well-blazed fashion with numerous open-source options available. In contrast my Node library I used to generate and validate an XML document at work last month cannot read in its own XML output. It’s a boon for efficiency. The only downside Java really has is that it’s a bit harder to “hack on” a dynamic, evolving JSON structure so it may be a bad fit for organizational reasons if your company lacks a cohesive, mature Engineering staff.
  - chasd00 3y ago
    my biggest gripe with old Spring was how far you had to go to get "hello world" on the browser when starting from zero. I never would have thought embedding the whole application server would be a good idea but SpringBoot proved me wrong. That plus the annotation based config vs xml files is what made fast development with Spring possible (in my mind). Also, Spring would be a miserable experience if it were not for Maven/Gradle. Have you ever counted the jar files included in a typical SpringBoot+Spring-Security+Spring-Data app?

nobleach 3y ago

So far the responses have been lukewarm to negative. I'm all for a framework as big as Spring, blazing the trail to use Virtual Threads! I haven't used Spring Boot in a few years, and Webflux was a paradigm shift that didn't interest me. It'd be nice to see what this does for the framework.

hashmash 3y ago
Where can we read about the responses?
- nobleach 3y ago
  sorry, I meant the 8 comments here on HN. (there are quite a few more now)

nprateem 3y ago

I just wish there was an admin generator like django's

wiseowise 3y ago

How’s performance? Is it better? Any benchmarks?

pylua 3y ago

I wonder if there will be any tools to detect pinning or synchronized use to help with the virtual threads transition. Blockhound I have gound useful for detecting blocking in non blocking areas.

mping 3y ago
There is a flag you can pass to the JVM to emit a log when a thread is pinned. It can also log a stack trace to show the call stack.

vkaku 3y ago

Moving the needle. But still as bloated as it can get. Never was invested in anything beyond Java SE, now I'm never going to invest in Java SE again.