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.
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?
No, you won't. People who gripe about spring didn't bother to do things the spring way. If you wrote your own DAL, you did it wrong. JpaRepositories and the like are the way. If you wrote your own JSON serializer/deserializer you did it wrong, Spring includes Jackson and will do it for you (YMMV). If you rolled your own authentication, you did it wrong. Spring Security can magically lock down your app with as little as a single configuration method, providing jwt/oauth/openid-connect enterprise security out of the box.
The issue with spring boot is not it's feature-set or it's robustness. It's with it's heavy handedness to force you down the "spring way". Annotation driven. Extending provided interfaces. Making it "sticky" and impossible to remove. Want to introduce gRPC? yeah, you're going to have to find a way to weave that into Netty or use a different port. It's robust enough just up unto a point where you hit a roadblock and have to dig deep deep into Spring land to understand whats going on.
It's still the best framework for standard crud web api's and such with Java. Though micronauts is quickly approaching. You can't go wrong choosing spring boot in 2023 if your intention is to ship in 2024. Whether or not that codebase is solid in 2027 is another matter.
Spring Boot is very productive but things can get very hairy when debugging auto configuration or understanding why a bean is missing from the context.
Running Boot in a container is also not great due to the memory requirements needed for bootstrap (min 0.5 Gi). I know GraalVm makes this better but compile times are still too painful.
I also think the push to make Reactor the default choice was a mistake (deprecating RestTemplate). The reactive model in Java feels unnatural and it can be very hard to debug.
I am working with Go now and don’t miss Spring Boot that much but it still has a place in my heart for the amazing community and docs.
I think that’s the source of negativity for the HN crowd. It’s boring, predictable, mature enterprise grade software that quietly gets the job done. It’s too similar to what they are forced to work with in $DAYJOB, instead of the exotic, fun frameworks they’d rather be playing with that you always read about here.
To add to the sibling comments, you'll also enjoy the monster amount of introspection made available in the combination of the JVM and JMX exposed via the Spring actuator endpoints. We regularly adjust logging levels of running pods in order to sniff out errant behavior versus bouncing them to fiddle with some log level. I have yet to play with a software stack that is designed for as much in-flight tuning as Spring on the JVM
Don't overlook @ConfigurationProperties <https://docs.spring.io/spring-boot/docs/3.1.1/reference/html...> as a way of strongly typing any configuration knobs that your application may require. That not only allows static typing to avoid the hazardous @Value("some.vaule.oops") but it also means that IJ will tab complete (with typechecks) in your application.{properties,json,yaml,whatever}
Spring is too automagical, often breaks with new releases, eats incredible amounts of memory, requires too much time to deal with its problems, produces stacktraces longer than my program. It's terrible, honestly.
Despite the all-in opinion in this particular thread, my take is a little more nuanced. The modern versions of Spring are a breath of fresh air (no pun) compared to the older ones. It still does have a bit of a kitchen sink feel when you build something non-trivial, and some of the magic of the boot approach can become hard to reason about. You may prefer a simpler worldview of an alternative runtime, and you can also benefit from shorter compiles/quicker startup, etc.
That said, the downsides aren't really that bad. It's got a strong community, will obviously still be around in 5 years, and the JVM is seeing strong investment and modernization. All in all, it'd be a strong contender if I was putting my money on the line. I'm still a fan of the simplest-thing-that-can-work approach (in the old days it was Jetty + Guice + whatever else you wanted), but modern Spring isn't all that far off from the experience anymore.
Spring is very good software, and basically and object oriented language will need to use stuff like it after enterprises throw their stack of requirements at it for 20+ years and following 20 years of technology evolution.
Yes its been tied to many java architectural fashion boondoggles of the past (XML config madness, XML namespace magic, overly heavyweight serverside HTML rendering, JSP tag madness, software patterns) but I still turn to it for basic code structuring in any JVM app.
Boot is pretty good ... until its not. If you are doing garden variety web services it gets you up and running fairly well. If you need to do anything fancy with routing or raw data in the html request/response, then it is not. And Spring is now so synonymous with Spring Boot that it kind of isn't a good thing.
Spring also isn't a pure open source project, it has a company trying to constantly steer it to revenue production, but as those types of entities go, stewardship has been decent. Normally things like that have about four or five years of trying to use open source for market expansion before impatience/greed/frustration sits in and they go for the closed source grab (see: Hashicorp recently). 20 years is a remarkable run for something like that.
Spring before spring-boot was an unreadable sea of unique xml. Spring-boot is a guardrail that steers you into the correct usage of the spring framework.
You will not, it's a fine choice for a software stack. There have been startup time problems, which Spring has been doing an excellent job of addressing. There's also been some silly performance problems which afaik have been addressed.
We personally use Quarkus and it's also pretty good. I think the Quarkus story has driven spring towards having a better story and both are pretty excellent stacks to go with.
A stacktrace in a Spring app can be painful to see. Tons of Spring code inbetween layers of your own app. Sometimes it has made me wonder, what happened with just plain old method invocations?
Granted, it can probable be helpful in many ways, but it comes at a price. But I think improvements in developer tooling will make annotation-driven programming unmodern. I see a renaissance coming for plain old programming.
In six months no but in 1-2 years yes. Spring has large tentacles so that when you start using it all code is coupled to Spring Boot and it's dependencies. I.e, the code you write is useless without Spring Boot, it is difficult to separate your code from Spring Boot. Now when technology changes you will have major refactor work i.e, like when Spring Boot moved from Dropwizard to Micrometer. It is possible to mitigate but takes advanced skills.
First, that Spring it's bloated. Spring now has a wide extension of modules that you may or may not need. Most of those modules won't even be added in your classpath unless specified in your pom.xml or build.gradle file. Very simple projects won't need the vast majority of the full Spring power.
Second, that a Spring project takes too much time to launch the web app (Compared against other frameworks doing the same task). Part of the reason it takes too much time to start comes from how the engine inflates the beans and injects it. On that same topic, other frameworks such as Micronaut are more lightweight because they don't bloat the framework as much as spring, thus the launch time is shorter. Also take into account that Java developers adore complexity in code structure so that also affects launch time.
Are you going to regret going with Spring? No, there is a lot of support from the community, if you have any issue you will find help in reddit and stackoverflow. It's a really mature framework.
However it's not the only option. There are other frameworks that could be a better choice for your use cases.
I thought the same thing 20 years ago. Still using spring. It's not a panacea, but compared to other technologies which came and went, it's been a great investment. The same could be said for Java, linux, python, bash, vi.
> Am I missing something? Will I regret this in six months?
Yes. One day you'll add another dependency to your classpath and your application will magically be doing something you didn't want or need. And the way to turn it off will be an undocumented annotation that only exists in the next version of spring boot, so you'll upgrade to that, and then a whole bunch of other stuff will break.
It's like you say, Spring Boot can get you from nothing to a production ready application in no time, it is reliable and the community support and documentation is great. It is also pretty flexible, up to a certain limit.
If your product happens to be something serving a zillion requests per second, using some exotic protocol, or doing some wildly complex calculations, then Spring might not be be the best choice. And it just so happens that the HN community's primary interest goes out to these rare exceptions and not to the 99% other projects in the real world.
The bulk of my full stack experience has been dotnet. But for the past 5 years I’ve moved into Java and Spring. I’m not a big fan of the JVM, but it works. However, Kotlin + Spring Boot is pretty fucking incredible. 1.x is kind of a pain in the ass, but 2 and 3 really blow me away at how well things integrate when you go with convention.
The major gripes I have is that _up-to-date_ documentation on the best ways compose a modern app using several modules where you aren’t fighting the tools. Official module docs tend to breeze over stuff. I can’t tell you how much time I’ve wasted rolling my own ____ and fighting against autoconfig then finding there’s a simple but poorly documented way of doing what I need. But even with that frustration, I feel like I’m able to launch projects faster using Spring Boot than dotnet.
one nit pick, Spring is more than Spring Boot although when people say "Spring" they're likely talking about Spring Boot.
You won't regret using it in 6 months except maybe for the fact that your backend will be just working and doing its thing and there's not really much else to do except watch it work.
Spring is old. The negativity comes from the the time where ppl would jump to Rails or Django instead of dealing with the config explosion/unnecessary complexities for startups/verbosity of the java at the time.
Now, we have modern java + simpflified saner default named spring boot, that's a different story
You probably won't regret it, Spring is a solid framework. But the issue with Spring in my experience is that it has constant breaking upgrades with various dependencies But this is more of an enterprise issue. Upgrade breaks a dependency, fixing that dependency will break another dependency, etc. While some people say Spring Boot is convention over configuration, I don't really buy that, the configuration is done via annotations which is still configuration. My other gripe with Spring is that despite it all being annotations, when it breaks it can be opaque about why it broke, or why it didn't bind something.
Usually HN culture with their Python and Ruby stuff.
I wouldn't change Jakarta EE, Spring, ASP.NET for framework of the day, with a subset of functionality and molass performance, unless told otherwise by customer architect.
Java 17, Hibernate, JPA, Spring Boot - all the way! Excellent combo! Reliable, high developer productivity, excellent community support, stable - have been using it for more than 8+ years now and won't think of using any other framework if I am going to build something in Java. Very easy to design, build, deploy, troubleshoot, maintain REST API Services! You won't go wrong at all if you choose Spring Boot.
For a new full stack project I'd use a full stack JavaScript framework, but spring boot is still awesome. Especially so when slow starts and higher resource consumption aren't as important as developer productivity, testability, reliability (which is pretty often).
Let me throw-in my 2c worth. I started my career in consulting with an in-house but Spring-inspired framework. I hated it, turned to other jobs that used other tech stacks; nowadays I largely consider myself a Pythonista. Lately, after about a decade from that first gig, I've finally decided to learn Spring properly and I've made good progress with it. Mind you, I decided to do so only because it seems like a good career move to know Spring in this economy.
So, my honest evaluation: learning Spring is frustrating and not an enjoyable experience at all. Just the sheer verbosity of things hurts my Pythonista soul. It's not just that Java is inherently more verbose than Python, it's just that "the Spring way" forces you to create three classes with little to no shortcuts around it; even the most opinionated Python/Node frameworks I've encountered wouldn't be that draconian. Coming from Python/Node/PHP/serverless, the framework's philosophy seems incomprehensibly monolithic.
All the layers of abstraction (and their resulting stack traces) make for an extremely confusing debugging experience especially for noobs.
*BUT*, I admit, judging a technology for its learning curve is not fair. I just had to vent my honest opinion on the experience.
I'm now at that point where I think I've grokked "the Spring way". That is, my Google searches on how to do X in Spring/troubleshoot a problem are smarter now. I've actually grown to appreciate it. (I'm pretty sure the Spring Gods would make me pay for the sheer hubris of this statement and will make me eat my words in the next feature I come up with in my side project.)
JpaRepositories are powerful magic. If Spring has any advantage over the frameworks I've come to love, it's this. JpaRepositories compensate for what Spring/Java lacks in brevity. Oh, also, not a Spring-specific advice but Lambdas and method references have made Java easier to write and has definitely deflated the number of classes I've had to create otherwise. Some would say that's just lipstick on a pig but I prefer to see it as an oasis in a desert.
Lastly, don't take this as advice for the backend you are building for a new start-up but I really see Spring's strength in that consulting CRUD-software market. If I can define specs in a legally-binding contract before writing a single line of code, if I can bang out a schema at the start of development and not worry about migrations, I would actually choose Spring. All the "corporate-rep" of Java won't hurt for these types of projects either.
But on the other hand, for environments where I need a lot of flexibility and lack the leisure of time almost always, I feel like Spring would be a development death march.
Misc notes:
1. I'm not actually learning vanilla Spring. I'm using Spring Boot alongside Vaadin. Overtime I've come to distinguish better between the two but maybe some percent of my frustrations in the learning phase is on Vaadin, not really Spring.
2. I made extensive use of ChatGPT in learning Spring. Even for such a boring/common tech, it's hilarious what ChatGPT gets wrong. But it also gets things right, giving advice in a level of clarity that blog posts and SO posts couldn't have provided. I would recommend anyone trying to learn Spring (or maybe any other framework/technology) to give ChatGPT a shot too. Even when it gets things wrong, the feedback loop that resembles actually talking to someone helps with the rubber ducking.
Again, all 2c worth of opinions from someone not even a year in this framework. Caveat lector!
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.
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.
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.
> 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.
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.
It would be pretty unusual for Spring not to take advantage of virtual threads, given the potential for dramatic performance improvements under many workloads.
Isn't it a success when you can build something that lasts 10+ years?
Enterprise has been relying on Java's compatibility promises for decades. It means the business decides when to invest, not the technology. The cost of re-validating and re-integrating a new system far, far outweighs that of re-writing the software, so you only upgrade the software when you're already having to upgrade the system.
Mark Reinhold managed to move Java to open-source, to frequent releases, and to supporting alternative languages (Kotlin for Google) and deployments (graalvm for containers) -- all while maintaining compatibility. He entirely effaced the notion that change means breakage.
Compare the breakage story in Python and C++ in the same time period.
To be fair, JDK8 represents a stable version of Java features and API that is most of what is needed for enterprise Java development. It is basically the stable inflection point of Java's evolution in terms of why Java took over enterprise development.
There was a core development intelligence level that JDK8 represented a sweet spot for (ahem, offshoring development). Which is really the core of the hate for Java these days although ... isn't Go the same trap?
Most of the post-JDK8 features are moving the language to what Groovy is, but closures, magic string templates, etc, but the IQ level of the programmers for that is a different market availability. Combined with the inherent deployment churn needed for modern JVM version turnover, which most enterprises simply don't have the organizational ability to do, means that JDK8 is going to stick around a LONG time.
Thankfully Java 11 LTS is now the bare minimum in our projects, and I even managed to push for Java 17 LTS on the latest one.
Even Android team has acknowledged that despite Kotlin, they needed to improve their support due to third party libraries, with Java 11 LTS last year, and Java 17 LTS coming this year. Both down to Android 12, naturally the usual subset without the graphics/UI related packages.
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.
[+] [-] nobleach|2 years ago|reply
[+] [-] hashmash|2 years ago|reply
[+] [-] nprateem|2 years ago|reply
[+] [-] greatpostman|2 years ago|reply
[+] [-] reactordev|2 years ago|reply
The issue with spring boot is not it's feature-set or it's robustness. It's with it's heavy handedness to force you down the "spring way". Annotation driven. Extending provided interfaces. Making it "sticky" and impossible to remove. Want to introduce gRPC? yeah, you're going to have to find a way to weave that into Netty or use a different port. It's robust enough just up unto a point where you hit a roadblock and have to dig deep deep into Spring land to understand whats going on.
It's still the best framework for standard crud web api's and such with Java. Though micronauts is quickly approaching. You can't go wrong choosing spring boot in 2023 if your intention is to ship in 2024. Whether or not that codebase is solid in 2027 is another matter.
[+] [-] ojhughes|2 years ago|reply
Running Boot in a container is also not great due to the memory requirements needed for bootstrap (min 0.5 Gi). I know GraalVm makes this better but compile times are still too painful.
I also think the push to make Reactor the default choice was a mistake (deprecating RestTemplate). The reactive model in Java feels unnatural and it can be very hard to debug.
I am working with Go now and don’t miss Spring Boot that much but it still has a place in my heart for the amazing community and docs.
[+] [-] _2z1p|2 years ago|reply
[+] [-] mdaniel|2 years ago|reply
Don't overlook @ConfigurationProperties <https://docs.spring.io/spring-boot/docs/3.1.1/reference/html...> as a way of strongly typing any configuration knobs that your application may require. That not only allows static typing to avoid the hazardous @Value("some.vaule.oops") but it also means that IJ will tab complete (with typechecks) in your application.{properties,json,yaml,whatever}
[+] [-] vbezhenar|2 years ago|reply
[+] [-] switchbak|2 years ago|reply
That said, the downsides aren't really that bad. It's got a strong community, will obviously still be around in 5 years, and the JVM is seeing strong investment and modernization. All in all, it'd be a strong contender if I was putting my money on the line. I'm still a fan of the simplest-thing-that-can-work approach (in the old days it was Jetty + Guice + whatever else you wanted), but modern Spring isn't all that far off from the experience anymore.
[+] [-] AtlasBarfed|2 years ago|reply
Yes its been tied to many java architectural fashion boondoggles of the past (XML config madness, XML namespace magic, overly heavyweight serverside HTML rendering, JSP tag madness, software patterns) but I still turn to it for basic code structuring in any JVM app.
Boot is pretty good ... until its not. If you are doing garden variety web services it gets you up and running fairly well. If you need to do anything fancy with routing or raw data in the html request/response, then it is not. And Spring is now so synonymous with Spring Boot that it kind of isn't a good thing.
Spring also isn't a pure open source project, it has a company trying to constantly steer it to revenue production, but as those types of entities go, stewardship has been decent. Normally things like that have about four or five years of trying to use open source for market expansion before impatience/greed/frustration sits in and they go for the closed source grab (see: Hashicorp recently). 20 years is a remarkable run for something like that.
[+] [-] nick__m|2 years ago|reply
spring => configuration over conventions
spring-boot => conventions over configuration
[+] [-] cogman10|2 years ago|reply
We personally use Quarkus and it's also pretty good. I think the Quarkus story has driven spring towards having a better story and both are pretty excellent stacks to go with.
[+] [-] mongol|2 years ago|reply
Granted, it can probable be helpful in many ways, but it comes at a price. But I think improvements in developer tooling will make annotation-driven programming unmodern. I see a renaissance coming for plain old programming.
[+] [-] oweiler|2 years ago|reply
It's boring tech, which is a good thing IMHO.
[+] [-] lfmunoz4|2 years ago|reply
[+] [-] m_0x|2 years ago|reply
First, that Spring it's bloated. Spring now has a wide extension of modules that you may or may not need. Most of those modules won't even be added in your classpath unless specified in your pom.xml or build.gradle file. Very simple projects won't need the vast majority of the full Spring power.
Second, that a Spring project takes too much time to launch the web app (Compared against other frameworks doing the same task). Part of the reason it takes too much time to start comes from how the engine inflates the beans and injects it. On that same topic, other frameworks such as Micronaut are more lightweight because they don't bloat the framework as much as spring, thus the launch time is shorter. Also take into account that Java developers adore complexity in code structure so that also affects launch time.
Are you going to regret going with Spring? No, there is a lot of support from the community, if you have any issue you will find help in reddit and stackoverflow. It's a really mature framework.
However it's not the only option. There are other frameworks that could be a better choice for your use cases.
[+] [-] eweef3334|2 years ago|reply
[+] [-] lmm|2 years ago|reply
Yes. One day you'll add another dependency to your classpath and your application will magically be doing something you didn't want or need. And the way to turn it off will be an undocumented annotation that only exists in the next version of spring boot, so you'll upgrade to that, and then a whole bunch of other stuff will break.
[+] [-] matwood|2 years ago|reply
[+] [-] misja111|2 years ago|reply
If your product happens to be something serving a zillion requests per second, using some exotic protocol, or doing some wildly complex calculations, then Spring might not be be the best choice. And it just so happens that the HN community's primary interest goes out to these rare exceptions and not to the 99% other projects in the real world.
[+] [-] moribvndvs|2 years ago|reply
The major gripes I have is that _up-to-date_ documentation on the best ways compose a modern app using several modules where you aren’t fighting the tools. Official module docs tend to breeze over stuff. I can’t tell you how much time I’ve wasted rolling my own ____ and fighting against autoconfig then finding there’s a simple but poorly documented way of doing what I need. But even with that frustration, I feel like I’m able to launch projects faster using Spring Boot than dotnet.
[+] [-] chasd00|2 years ago|reply
You won't regret using it in 6 months except maybe for the fact that your backend will be just working and doing its thing and there's not really much else to do except watch it work.
[+] [-] gloryjulio|2 years ago|reply
Now, we have modern java + simpflified saner default named spring boot, that's a different story
[+] [-] ecshafer|2 years ago|reply
[+] [-] pjmlp|2 years ago|reply
I wouldn't change Jakarta EE, Spring, ASP.NET for framework of the day, with a subset of functionality and molass performance, unless told otherwise by customer architect.
[+] [-] time4tea|2 years ago|reply
It's a tricky question to get a real answer, due to all the vested interests, lack of real research, and differing views of "what is good"
Which is better, Amiga or ST (Amiga!)
[+] [-] itpragmatik|2 years ago|reply
[+] [-] willsmith72|2 years ago|reply
[+] [-] topspin|2 years ago|reply
Only if you plan to collect kudos with it on HN. Otherwise you'll be fine.
[+] [-] paulddraper|2 years ago|reply
There's a huge difference between "Spring pre-Boot" and "Spring post-Boot."
Not quite as significant as Angular 1 vs Angular 2, but close.
[+] [-] ninjazee124|2 years ago|reply
[+] [-] yallpendantools|2 years ago|reply
So, my honest evaluation: learning Spring is frustrating and not an enjoyable experience at all. Just the sheer verbosity of things hurts my Pythonista soul. It's not just that Java is inherently more verbose than Python, it's just that "the Spring way" forces you to create three classes with little to no shortcuts around it; even the most opinionated Python/Node frameworks I've encountered wouldn't be that draconian. Coming from Python/Node/PHP/serverless, the framework's philosophy seems incomprehensibly monolithic.
All the layers of abstraction (and their resulting stack traces) make for an extremely confusing debugging experience especially for noobs.
*BUT*, I admit, judging a technology for its learning curve is not fair. I just had to vent my honest opinion on the experience.
I'm now at that point where I think I've grokked "the Spring way". That is, my Google searches on how to do X in Spring/troubleshoot a problem are smarter now. I've actually grown to appreciate it. (I'm pretty sure the Spring Gods would make me pay for the sheer hubris of this statement and will make me eat my words in the next feature I come up with in my side project.)
JpaRepositories are powerful magic. If Spring has any advantage over the frameworks I've come to love, it's this. JpaRepositories compensate for what Spring/Java lacks in brevity. Oh, also, not a Spring-specific advice but Lambdas and method references have made Java easier to write and has definitely deflated the number of classes I've had to create otherwise. Some would say that's just lipstick on a pig but I prefer to see it as an oasis in a desert.
Lastly, don't take this as advice for the backend you are building for a new start-up but I really see Spring's strength in that consulting CRUD-software market. If I can define specs in a legally-binding contract before writing a single line of code, if I can bang out a schema at the start of development and not worry about migrations, I would actually choose Spring. All the "corporate-rep" of Java won't hurt for these types of projects either.
But on the other hand, for environments where I need a lot of flexibility and lack the leisure of time almost always, I feel like Spring would be a development death march.
Misc notes:
1. I'm not actually learning vanilla Spring. I'm using Spring Boot alongside Vaadin. Overtime I've come to distinguish better between the two but maybe some percent of my frustrations in the learning phase is on Vaadin, not really Spring.
2. I made extensive use of ChatGPT in learning Spring. Even for such a boring/common tech, it's hilarious what ChatGPT gets wrong. But it also gets things right, giving advice in a level of clarity that blog posts and SO posts couldn't have provided. I would recommend anyone trying to learn Spring (or maybe any other framework/technology) to give ChatGPT a shot too. Even when it gets things wrong, the feedback loop that resembles actually talking to someone helps with the rubber ducking.
Again, all 2c worth of opinions from someone not even a year in this framework. Caveat lector!
[+] [-] coderoffortune|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] pylua|2 years ago|reply
Blockhound I have gound useful for detecting blocking in non blocking areas.
[+] [-] vkaku|2 years ago|reply
Never was invested in anything beyond Java SE, now I'm never going to invest in Java SE again.
[+] [-] oblio|2 years ago|reply
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.
[+] [-] wiseowise|2 years ago|reply
[+] [-] fnord77|2 years ago|reply
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.
[+] [-] microflash|2 years ago|reply
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-B...
[1]: https://github.com/openrewrite/rewrite
[+] [-] nforgerit|2 years ago|reply
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.
[+] [-] geodel|2 years ago|reply
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|2 years ago|reply
[+] [-] xyst|2 years ago|reply
[+] [-] w10-1|2 years ago|reply
Enterprise has been relying on Java's compatibility promises for decades. It means the business decides when to invest, not the technology. The cost of re-validating and re-integrating a new system far, far outweighs that of re-writing the software, so you only upgrade the software when you're already having to upgrade the system.
Mark Reinhold managed to move Java to open-source, to frequent releases, and to supporting alternative languages (Kotlin for Google) and deployments (graalvm for containers) -- all while maintaining compatibility. He entirely effaced the notion that change means breakage.
Compare the breakage story in Python and C++ in the same time period.
[+] [-] AtlasBarfed|2 years ago|reply
There was a core development intelligence level that JDK8 represented a sweet spot for (ahem, offshoring development). Which is really the core of the hate for Java these days although ... isn't Go the same trap?
Most of the post-JDK8 features are moving the language to what Groovy is, but closures, magic string templates, etc, but the IQ level of the programmers for that is a different market availability. Combined with the inherent deployment churn needed for modern JVM version turnover, which most enterprises simply don't have the organizational ability to do, means that JDK8 is going to stick around a LONG time.
[+] [-] pjmlp|2 years ago|reply
Even Android team has acknowledged that despite Kotlin, they needed to improve their support due to third party libraries, with Java 11 LTS last year, and Java 17 LTS coming this year. Both down to Android 12, naturally the usual subset without the graphics/UI related packages.
[+] [-] volkadav|2 years ago|reply
[+] [-] kitanata|2 years ago|reply
[deleted]