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.

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.

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.

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.

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.

> 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?

The point isn't that one should reinvent the way that Tomcat is started, but that Spring Boot (by default) is using action at a distance and runtime reflection which have serious downsides if you want to understand what's actually going on because you're a) new to the technology, or b) have to debug some weird edge case.

The alternative is using explicit, reflection-less code - which you can do even with Spring, although it's experimental: https://github.com/spring-projects-experimental/spring-fu

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

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

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

An interested reader can decide for themselves:

https://github.com/spring-projects/spring-boot/tree/main/spr...