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