9 ms·

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. sprin

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. spring => configuration over conventions spring-boot => conventions over configuration

gabereiser 3y ago
Mostly agree with this, the issue was that Spring Framework 3 introduced a new way of doing configuration with the @Configuration annotation. Up until then it was all xml driven (some minor packages like spring-integration still required it) bean soup. The advent of the annotation driven configuration paved way for spring-boot to provide sane defaults to the framework (previously reserved for certified spring framework engineers like myself to define in xml that we copied time and time again). You nailed it though with Spring being configuration over convention and Spring Boot being the opposite. At the time, there was a competing web framework that was really simple to build with called Rails that made the mindset shift to ease-of-use from a dev standpoint away from ease-of-use from an ops standpoint.
jonhohle 3y ago
I disagree but know I’m in the minority. I would take Spring config XML over the tightly coupled mess of Spring config annotations and code. Circa 2006, Spring config was about binding decoupled POJOs together and code didn’t require any build time dependency on Spring. Now Spring is required at build time and objects expect to be instantiated as beans, and unit tests either require a minimal spring context or some other method of injecting dependencies that would have otherwise existed as a constructor arg or mutator anyway. Now “config” is fully Turing complete as opposed to declarative. Yuck! I’m no fan of XML, but config as code is no longer config, imho.
- vbezhenar 3y ago
  I liked original Spring idea of being actually non-invasive framework as well and I never had any issues with Spring XML config. It worked for me and Idea has decent autocomplete for it. There was time when Spring was considered lightweight. Oh, well. Spring Boot is when it all went downhill.
  - sverhagen 3y ago
    I'm sure you can find terrible implementations using Spring/Spring Boot. But the only annotation you have to use all the time is @Component (or @Service) and you could still externalize that, even without XML configuration, by using @Bean in an @Configuration class. Even if you're not so worried about compartmentalizing your bean wiring, the number of annotations is often very minimal, and you can focus a lot on actually writing your best business code. At the end of the day, complex applications need to deal with complexity somehow. The debate becomes: do you want to adopt and trust Spring's "under the hood" complexity, or is your team going to roll a lot of that themselves.
    - vbezhenar 3y ago
      Typical spring boot application is absolutely full of annotations and extended helper classes for configuration, and implicitly running starter classes for further configuration. My Spring Boot application launches entire tomcat under the hood without a single line of code. How terrible is that? My preference when it comes to configuration is just pure code. Not @Configuration. Just construct necessary objects, wire them up and go. Just like with Golang. So no magic, all I wrote will be executed and no more. No classpath scanning will be performed. No code will be generated (I can tolerate code generation at pre-compile phase, so I can easily browse it with my IDE, something like mapstruct, but I hate all those java.lang.Proxy-ies, all those asm-generated wrappers around interfaces just so I can write @Transactional, like it matters). I can actually fight Spring Boot. I can write XML configuration or configure things with code myself. But I live and work in community and I expected to follow so-called "commonly accepted" practice.
      - sverhagen 3y ago
        > How terrible is that? Not terrible at all? For most people (not you, OF COURSE) I would ask: could you run Tomcat better than Spring can? Then why care?
        Tainnor 3y ago
- ivan_gammel 3y ago
  Spring annotations have runtime scope (one annotation per class is usually sufficient for injection if Spring can resolve all constructor arguments). You can disregard them and wire your POJOs manually via constructors in unit tests. Spring context thus is really required only in integration tests, in unit tests it is optional and may be a code smell (testing too big scope).
sorokod 3y ago
Spring Boot takes care of bundling libraries comprising the Spring universe into version compatible units. That is pretty much it.
- ojhughes 3y ago
  Starters and dependency management are key features of boot but it’s a big understatement to say “that’s pretty much it”. It includes actuators, the auto configuration system, embedded web server and configuration properties
  - sorokod 3y ago
    An interested reader can decide for themselves: https://github.com/spring-projects/spring-boot/tree/main/spring-boot-project https://github.com/spring-projects/spring-boot/tree/main/spr...

gabereiser 3y ago

Mostly agree with this, the issue was that Spring Framework 3 introduced a new way of doing configuration with the @Configuration annotation. Up until then it was all xml driven (some minor packages like spring-integration still required it) bean soup. The advent of the annotation driven configuration paved way for spring-boot to provide sane defaults to the framework (previously reserved for certified spring framework engineers like myself to define in xml that we copied time and time again). You nailed it though with Spring being configuration over convention and Spring Boot being the opposite. At the time, there was a competing web framework that was really simple to build with called Rails that made the mindset shift to ease-of-use from a dev standpoint away from ease-of-use from an ops standpoint.

jonhohle 3y ago

I disagree but know I’m in the minority. I would take Spring config XML over the tightly coupled mess of Spring config annotations and code. Circa 2006, Spring config was about binding decoupled POJOs together and code didn’t require any build time dependency on Spring. Now Spring is required at build time and objects expect to be instantiated as beans, and unit tests either require a minimal spring context or some other method of injecting dependencies that would have otherwise existed as a constructor arg or mutator anyway. Now “config” is fully Turing complete as opposed to declarative. Yuck! I’m no fan of XML, but config as code is no longer config, imho.

vbezhenar 3y ago
I liked original Spring idea of being actually non-invasive framework as well and I never had any issues with Spring XML config. It worked for me and Idea has decent autocomplete for it. There was time when Spring was considered lightweight. Oh, well. Spring Boot is when it all went downhill.
- sverhagen 3y ago
  I'm sure you can find terrible implementations using Spring/Spring Boot. But the only annotation you have to use all the time is @Component (or @Service) and you could still externalize that, even without XML configuration, by using @Bean in an @Configuration class. Even if you're not so worried about compartmentalizing your bean wiring, the number of annotations is often very minimal, and you can focus a lot on actually writing your best business code. At the end of the day, complex applications need to deal with complexity somehow. The debate becomes: do you want to adopt and trust Spring's "under the hood" complexity, or is your team going to roll a lot of that themselves.
  - vbezhenar 3y ago
    Typical spring boot application is absolutely full of annotations and extended helper classes for configuration, and implicitly running starter classes for further configuration. My Spring Boot application launches entire tomcat under the hood without a single line of code. How terrible is that? My preference when it comes to configuration is just pure code. Not @Configuration. Just construct necessary objects, wire them up and go. Just like with Golang. So no magic, all I wrote will be executed and no more. No classpath scanning will be performed. No code will be generated (I can tolerate code generation at pre-compile phase, so I can easily browse it with my IDE, something like mapstruct, but I hate all those java.lang.Proxy-ies, all those asm-generated wrappers around interfaces just so I can write @Transactional, like it matters). I can actually fight Spring Boot. I can write XML configuration or configure things with code myself. But I live and work in community and I expected to follow so-called "commonly accepted" practice.
    - sverhagen 3y ago
      > How terrible is that? Not terrible at all? For most people (not you, OF COURSE) I would ask: could you run Tomcat better than Spring can? Then why care?
      - Tainnor 3y ago
ivan_gammel 3y ago
Spring annotations have runtime scope (one annotation per class is usually sufficient for injection if Spring can resolve all constructor arguments). You can disregard them and wire your POJOs manually via constructors in unit tests. Spring context thus is really required only in integration tests, in unit tests it is optional and may be a code smell (testing too big scope).

sorokod 3y ago

Spring Boot takes care of bundling libraries comprising the Spring universe into version compatible units. That is pretty much it.

ojhughes 3y ago
Starters and dependency management are key features of boot but it’s a big understatement to say “that’s pretty much it”. It includes actuators, the auto configuration system, embedded web server and configuration properties
- sorokod 3y ago
  An interested reader can decide for themselves: https://github.com/spring-projects/spring-boot/tree/main/spring-boot-project https://github.com/spring-projects/spring-boot/tree/main/spr...