8 ms·

No, just no. Performance and debugging are just plain horrible. The spring team loves to force you into their automagic shit and this bean stuff is so annoying.

No, just no. Performance and debugging are just plain horrible. The spring team loves to force you into their automagic shit and this bean stuff is so annoying. You almost got no compile time safety in this stack. It's the bane of my existence. I'd like to know that a compiled program will run. That seems virtually impossible with java/spring boot.

didntcheck 3y ago
It's not quite as good as compile-time or type-based guarantees, but IME configuration errors with Spring are almost always flagged up immediately on application startup. As long as you have at least one test that initializes the application context (I.e. @SpringBootTest) then this should be caught easily
pylua 3y ago
Spring is basically a standard in itself and it is easier to hire people in it. It also normalizes large pieces of the backend application so even though they are written by different people they are similar. Once you learn the annotation based configuration it also saves a lot of time. The performance is valid but it will only keep improving.
- RamblingCTO 3y ago
  To be honest, over the almost 5 years we're into using it, I spent more time debugging funky stuff due to that design that it would've cost me to just do it by hand. By a big margin.
  - loginatnine 3y ago
    As a Spring power user, you sound like you're ranting against something you don't/didn't understand.
    - RamblingCTO 3y ago
      It's weird that some people including you directly attack my competence. As a power user you should have plenty of experience getting something to work that is not properly document, does not work how the documentation promised it to, or has weird problems on top of it. Look at idiotic things like this: https://github.com/spring-projects/spring-boot/issues/33044 https://github.com/spring-projects/spring-boot/issues/33044 Take any similar issue and you'll see a bunch of people who try to find a solution for them because they just aren't repeatable at all. The underlying issue is the auto configuration doing things you can't follow quite properly. It's like it wasn't mean to be understood. Issues like the one I linked above also show me that the spring dev crowd also doesn't understand the ecosystem anymore. The problem is complexity and automagic. /e: this is what I mean in a nutshell https://news.ycombinator.com/item?id=37839306 https://news.ycombinator.com/item?id=37839306 and that will happen regardless of how much you "learnt" about spring boot ...
      - pylua 3y ago
        I can definitely relate to these sorts of problems and I have faced them many times. Honestly I have gotten so use to reading the decompiled source of code in IntelliJ to determine how to enable / disable items it is second nature. Given the expressiveness and power behind the system that is a trade off I am willing to take. To a certain extent I think it is a trade off of using a tool that has so many permutations. What you are saying is certainly justified.
Fabricio20 3y ago
It's funny to see this perspective! I used to work in a few companies locally who had adopted the early java-ee style for their applications and my experience is exactly the opposite. When going to spring I'm usually diagnosing issues on the application layer (ie: business issues, not framework issues), while on the java-ee applications I was often having to fix issues down at the custom persistence layer each company had, etc.. I see where you come from having looked at the "old" spring stack (non -boot), and I can see people getting mad over the configuration hell and how stuff is hidden behind xml.. Much like how java-ee is!
- chasd00 3y ago
  Iirc spring was invented as a response to the j2ee madness.
- bedobi 3y ago
  Spring and Java EE are not the only options out there. These days DropWizard, Ktor and others are MUCH better alternatives.
twh270 3y ago
We've adopted Quarkus and it's been a breath of fresh air. Excellent all around, DX, performance, features, it's all been good.
- m_0x 3y ago
  In Quarkus, can you inject different beans depending on configuration?
  - michens 3y ago
    Yes, either @IfBuildProfile/@DefaultBean if your logic depends on build profile, or @LookupIfProperty/@LookupUnlessProperty if it depends on property value
- RamblingCTO 3y ago
  Have you had the chance to compare it to Micronaut?
StevePerkins 3y ago
I'm not sure what "no compile time safety in this stack" even means in the context of a strongly-typed compiled language. If you are referring to the dependency injection container making use of reflection, then Spring Native graduated from experimental add-on to part of the core framework some years ago. You can now opt for Quarkus/Micronaut-style static build-time dependency injection, and even AOT compilation to Go-style native executables, if you're willing to trade off the flexibility that comes with avoiding reflection. For example, not being able to use any of the "@ConditionalOnXXX" annotations to make your DI more dynamic. (Personally, I don't believe that those trade-offs are worth it in most cases. And I believe that all the Spring magic in the universe doesn't amount to 10% of what Python brings to the table in a minimal Django/Flask/FastAPI microservice. But the option is there if your use case truly calls for it.) Honestly, I've never run into anyone who considers Spring to be "the bane of their existence", where the real issue wasn't simply that the bulk of their experience was in something else. Where they weren't thrown into someone else's project, and resent working with decisions made by other people, but don't want to either dig in and learn the tech or else search for a new job where they get to make the choices on a greenfield project.
- lmm 3y ago
  My experience, from memory; a few of the details might be wrong (e.g. it probably wasn't Redis, but it was some kind of datastore) but the basic experience is what happened: Q: Why does my webapp run on most of our tomcats but not this one? A: That tomcat server has the redis client libraries on the classpath, so Spring Boot automatically started up a connection pool connecting to localhost on the default port, and automatically includes that in the healthcheck endpoint. Since redis isn't actually running there, it fails to connect, so the healthcheck always fails and the app never shows as running, even though your code is working fine. Q: How do I turn that off? A: Upgrade to the next version of Spring boot and then add this undocumented annotation to your configuration Q: How was I supposed to figure any of that out? A: Hahaha fuck you Spring proper is fine, useful even. Spring boot is an absolute nightmare of COME FROM style incomprehensibility.
  - RamblingCTO 3y ago
vmaurin 3y ago
The issue with Spring ecosystem is that people use it without knowing why or which problem it solves but because almost everyone is using it. And most of the time, they don't need Spring (maybe a company like Netflix did, but it didn't prove to be the right choice at the end)
smrtinsert 3y ago
Performance and debugging simple, and compile time safety is Javas core domain. I think you're over focusing on proxying or enhancement of beans, but if you look at a documentation for a reasonable amount of time there's really nothing to it.
throwaway1492 3y ago
[flagged]
- geodel 3y ago
  "This person" makes rather relevant comment on Spring boot's severe shortcomings. Whereas your comment from throwaway account is blabbering nonsense.
  - throwaway1492 3y ago
    Well that supports my point actually, that these "short comings" aren't short comings at all if one takes the time to learn the framework. Blabbering? People often say that who have no valid technical or intellectual response.
    - RamblingCTO 3y ago
      I don't see anything beyond ad hominem. That reveals more about yourself than you probably think. I'll move on then.
    - geodel 3y ago
      Why would framework be correct if the premise of heavy runtime reflection based approach itself is bad? You can spend your lifetime learning this framework, others can simply reject on first principles' basis.
      - wiseowise 3y ago
        > Why would framework be correct if the premise of heavy runtime reflection based approach itself is bad? Because the framework allows zero reflection approach.
  - krooj 3y ago
    Their comments on the shortcomings boil down to, "I didn't spend any time learning how this works."
krooj 3y ago
This is just... ignorance; your argument is basically, "I don't understand/want to learn how X works; therefore, X must be garbage"
- RamblingCTO 3y ago
  If you read more of my responses you'll see that I've been a Spring user for quite some time and know how it works. I just dislike how it works. Do you have any argumentation or did you just want to call me ignorant?
  - krooj 3y ago
    Yes, and now I'm even more convinced that you have no idea what you're doing or talking about in regards to the framework and it's ecosystem.
wing-_-nuts 3y ago
What do you propose as an alternative? Something like Micronaut trades more compile time for stricter checks and faster runtime. Do you use something like that?
- sea-gold 3y ago
  I really like http4k. http4k[0] is a lightweight but fully-featured HTTP toolkit written in pure Kotlin that enables the serving and consuming of HTTP services in a functional and consistent way. http4k consists of a lightweight core library, http4k-core, providing a base HTTP implementation and Server/Client implementations based on the JDK classes. Further servers, clients, serverless, templating, websockets capabilities are then implemented in add-on modules. http4k apps can be simply mounted into a running Server, Serverless platform, or compiled to GraalVM and run as a super-lightweight binary. Apart the from Kotlin StdLib, http4k-core module has ZERO dependencies and weighs in at ~1mb. Add-on modules only have dependencies required for specific implementation. [0] https://www.http4k.org/documentation/ https://www.http4k.org/documentation/
  - RamblingCTO 3y ago
    Sounds nice, I'll have a look! Cheers
- RamblingCTO 3y ago
  I implemented a microservice with micronaut starting 3,5 years back. The fragility of krush/exposed is not very fun tho. we introduce another hurdle because we only use Kotlin. I'm open for ideas though. PS: we replaced/will replace all microservices with Go.
  - wing-_-nuts 3y ago
    Hah, yeah, we have a number of microservices implemented with golang. As 'clunky' as the language can feel sometimes the tooling is first class.
    - 3y ago
dimgl 3y ago
I completely agree with this. Spring was an absolute nightmare during the short period of time where I had the misfortune of using it. It also didn't help that the codebase was a monstrosity... classes following no design patterns and having 40k lines. But still...
- RamblingCTO 3y ago
  Agreed! Have fun reading spring source code or documentation to find anything. An obscure stackoverflow answer from 10 years back will hold the answer though. Fun times
misja111 3y ago
FYI, you can still use XML based configuration in Spring. The choice is yours. See https://docs.spring.io/spring-framework/docs/4.2.x/spring-framework-reference/html/xsd-configuration.html https://docs.spring.io/spring-framework/docs/4.2.x/spring-fr... I agree it is not common to do it, most teams follow the autoconfiguration madness.
bedobi 3y ago
100% agree, Java and Spring are a mess and there's no justifiable reason to use them in 2023 (and no, "that's what we've always used" isn't a good justification) Like srsly even DropWizard is better than Spring lol, let alone other even simpler frameworks like Ktor which is built on a much improved language over Java
nameless912 3y ago
That has not been my experience on the inside - I spend most of my days working on a Spring Boot based service at Netflix and frankly it's one of the most effortless environments I've ever worked in. Granted, there's a lot of ecosystem support from the rest of the company, but things are very low effort, and generally very predictable. I can usually drop a breakpoint in a debugger in exactly the right spot and find a problem immediately.

didntcheck 3y ago

It's not quite as good as compile-time or type-based guarantees, but IME configuration errors with Spring are almost always flagged up immediately on application startup. As long as you have at least one test that initializes the application context (I.e. @SpringBootTest) then this should be caught easily

pylua 3y ago

Spring is basically a standard in itself and it is easier to hire people in it. It also normalizes large pieces of the backend application so even though they are written by different people they are similar. Once you learn the annotation based configuration it also saves a lot of time. The performance is valid but it will only keep improving.

RamblingCTO 3y ago
To be honest, over the almost 5 years we're into using it, I spent more time debugging funky stuff due to that design that it would've cost me to just do it by hand. By a big margin.
- loginatnine 3y ago
  As a Spring power user, you sound like you're ranting against something you don't/didn't understand.
  - RamblingCTO 3y ago
    It's weird that some people including you directly attack my competence. As a power user you should have plenty of experience getting something to work that is not properly document, does not work how the documentation promised it to, or has weird problems on top of it. Look at idiotic things like this: https://github.com/spring-projects/spring-boot/issues/33044 https://github.com/spring-projects/spring-boot/issues/33044 Take any similar issue and you'll see a bunch of people who try to find a solution for them because they just aren't repeatable at all. The underlying issue is the auto configuration doing things you can't follow quite properly. It's like it wasn't mean to be understood. Issues like the one I linked above also show me that the spring dev crowd also doesn't understand the ecosystem anymore. The problem is complexity and automagic. /e: this is what I mean in a nutshell https://news.ycombinator.com/item?id=37839306 https://news.ycombinator.com/item?id=37839306 and that will happen regardless of how much you "learnt" about spring boot ...
    - pylua 3y ago
      I can definitely relate to these sorts of problems and I have faced them many times. Honestly I have gotten so use to reading the decompiled source of code in IntelliJ to determine how to enable / disable items it is second nature. Given the expressiveness and power behind the system that is a trade off I am willing to take. To a certain extent I think it is a trade off of using a tool that has so many permutations. What you are saying is certainly justified.

Fabricio20 3y ago

It's funny to see this perspective! I used to work in a few companies locally who had adopted the early java-ee style for their applications and my experience is exactly the opposite. When going to spring I'm usually diagnosing issues on the application layer (ie: business issues, not framework issues), while on the java-ee applications I was often having to fix issues down at the custom persistence layer each company had, etc.. I see where you come from having looked at the "old" spring stack (non -boot), and I can see people getting mad over the configuration hell and how stuff is hidden behind xml.. Much like how java-ee is!

chasd00 3y ago
Iirc spring was invented as a response to the j2ee madness.
bedobi 3y ago
Spring and Java EE are not the only options out there. These days DropWizard, Ktor and others are MUCH better alternatives.

twh270 3y ago

We've adopted Quarkus and it's been a breath of fresh air. Excellent all around, DX, performance, features, it's all been good.

m_0x 3y ago
In Quarkus, can you inject different beans depending on configuration?
- michens 3y ago
  Yes, either @IfBuildProfile/@DefaultBean if your logic depends on build profile, or @LookupIfProperty/@LookupUnlessProperty if it depends on property value
RamblingCTO 3y ago
Have you had the chance to compare it to Micronaut?

StevePerkins 3y ago

I'm not sure what "no compile time safety in this stack" even means in the context of a strongly-typed compiled language. If you are referring to the dependency injection container making use of reflection, then Spring Native graduated from experimental add-on to part of the core framework some years ago. You can now opt for Quarkus/Micronaut-style static build-time dependency injection, and even AOT compilation to Go-style native executables, if you're willing to trade off the flexibility that comes with avoiding reflection. For example, not being able to use any of the "@ConditionalOnXXX" annotations to make your DI more dynamic. (Personally, I don't believe that those trade-offs are worth it in most cases. And I believe that all the Spring magic in the universe doesn't amount to 10% of what Python brings to the table in a minimal Django/Flask/FastAPI microservice. But the option is there if your use case truly calls for it.) Honestly, I've never run into anyone who considers Spring to be "the bane of their existence", where the real issue wasn't simply that the bulk of their experience was in something else. Where they weren't thrown into someone else's project, and resent working with decisions made by other people, but don't want to either dig in and learn the tech or else search for a new job where they get to make the choices on a greenfield project.

lmm 3y ago
My experience, from memory; a few of the details might be wrong (e.g. it probably wasn't Redis, but it was some kind of datastore) but the basic experience is what happened: Q: Why does my webapp run on most of our tomcats but not this one? A: That tomcat server has the redis client libraries on the classpath, so Spring Boot automatically started up a connection pool connecting to localhost on the default port, and automatically includes that in the healthcheck endpoint. Since redis isn't actually running there, it fails to connect, so the healthcheck always fails and the app never shows as running, even though your code is working fine. Q: How do I turn that off? A: Upgrade to the next version of Spring boot and then add this undocumented annotation to your configuration Q: How was I supposed to figure any of that out? A: Hahaha fuck you Spring proper is fine, useful even. Spring boot is an absolute nightmare of COME FROM style incomprehensibility.
- RamblingCTO 3y ago

vmaurin 3y ago

The issue with Spring ecosystem is that people use it without knowing why or which problem it solves but because almost everyone is using it. And most of the time, they don't need Spring (maybe a company like Netflix did, but it didn't prove to be the right choice at the end)

smrtinsert 3y ago

Performance and debugging simple, and compile time safety is Javas core domain. I think you're over focusing on proxying or enhancement of beans, but if you look at a documentation for a reasonable amount of time there's really nothing to it.

throwaway1492 3y ago

[flagged]

geodel 3y ago
"This person" makes rather relevant comment on Spring boot's severe shortcomings. Whereas your comment from throwaway account is blabbering nonsense.
- throwaway1492 3y ago
  Well that supports my point actually, that these "short comings" aren't short comings at all if one takes the time to learn the framework. Blabbering? People often say that who have no valid technical or intellectual response.
  - RamblingCTO 3y ago
    I don't see anything beyond ad hominem. That reveals more about yourself than you probably think. I'll move on then.
  - geodel 3y ago
    Why would framework be correct if the premise of heavy runtime reflection based approach itself is bad? You can spend your lifetime learning this framework, others can simply reject on first principles' basis.
    - wiseowise 3y ago
      > Why would framework be correct if the premise of heavy runtime reflection based approach itself is bad? Because the framework allows zero reflection approach.
- krooj 3y ago
  Their comments on the shortcomings boil down to, "I didn't spend any time learning how this works."

krooj 3y ago

This is just... ignorance; your argument is basically, "I don't understand/want to learn how X works; therefore, X must be garbage"

RamblingCTO 3y ago
If you read more of my responses you'll see that I've been a Spring user for quite some time and know how it works. I just dislike how it works. Do you have any argumentation or did you just want to call me ignorant?
- krooj 3y ago
  Yes, and now I'm even more convinced that you have no idea what you're doing or talking about in regards to the framework and it's ecosystem.

wing-_-nuts 3y ago

What do you propose as an alternative? Something like Micronaut trades more compile time for stricter checks and faster runtime. Do you use something like that?

sea-gold 3y ago
I really like http4k. http4k[0] is a lightweight but fully-featured HTTP toolkit written in pure Kotlin that enables the serving and consuming of HTTP services in a functional and consistent way. http4k consists of a lightweight core library, http4k-core, providing a base HTTP implementation and Server/Client implementations based on the JDK classes. Further servers, clients, serverless, templating, websockets capabilities are then implemented in add-on modules. http4k apps can be simply mounted into a running Server, Serverless platform, or compiled to GraalVM and run as a super-lightweight binary. Apart the from Kotlin StdLib, http4k-core module has ZERO dependencies and weighs in at ~1mb. Add-on modules only have dependencies required for specific implementation. [0] https://www.http4k.org/documentation/ https://www.http4k.org/documentation/
- RamblingCTO 3y ago
  Sounds nice, I'll have a look! Cheers
RamblingCTO 3y ago
I implemented a microservice with micronaut starting 3,5 years back. The fragility of krush/exposed is not very fun tho. we introduce another hurdle because we only use Kotlin. I'm open for ideas though. PS: we replaced/will replace all microservices with Go.
- wing-_-nuts 3y ago
  Hah, yeah, we have a number of microservices implemented with golang. As 'clunky' as the language can feel sometimes the tooling is first class.
  - 3y ago

dimgl 3y ago

I completely agree with this. Spring was an absolute nightmare during the short period of time where I had the misfortune of using it. It also didn't help that the codebase was a monstrosity... classes following no design patterns and having 40k lines. But still...

RamblingCTO 3y ago
Agreed! Have fun reading spring source code or documentation to find anything. An obscure stackoverflow answer from 10 years back will hold the answer though. Fun times

misja111 3y ago

FYI, you can still use XML based configuration in Spring. The choice is yours. See https://docs.spring.io/spring-framework/docs/4.2.x/spring-framework-reference/html/xsd-configuration.html https://docs.spring.io/spring-framework/docs/4.2.x/spring-fr... I agree it is not common to do it, most teams follow the autoconfiguration madness.

bedobi 3y ago

100% agree, Java and Spring are a mess and there's no justifiable reason to use them in 2023 (and no, "that's what we've always used" isn't a good justification) Like srsly even DropWizard is better than Spring lol, let alone other even simpler frameworks like Ktor which is built on a much improved language over Java

nameless912 3y ago

That has not been my experience on the inside - I spend most of my days working on a Spring Boot based service at Netflix and frankly it's one of the most effortless environments I've ever worked in. Granted, there's a lot of ecosystem support from the rest of the company, but things are very low effort, and generally very predictable. I can usually drop a breakpoint in a debugger in exactly the right spot and find a problem immediately.