Spring Boot

Why it's ranked here

The repository backs up the reputation. Work is split into core, module, and starter tiers with hundreds of independently declared subprojects, so a technology you do not use never reaches your classpath. Continuous integration runs on Linux and Windows across four Java levels. Formatting, style, and nullability checks run inside the build itself, and every contribution needs a signed certificate of origin. The cost is scale: this is infrastructure with a very large configuration surface, and building it from source needs a JDK newer than most teams run. Adopt it for the defaults, not for reading the code.

What's good

The core stays small on purpose. It declares two hard Spring dependencies and marks logging, Kotlin, validation, servlet, and JSON support as optional, so consumers pull only what they use. The operations module adds health endpoints, dimensional metrics through Micrometer, and an audit event framework reachable over HTTP or JMX from a single dependency. Bundles exist for messaging, persistence, security, templating, observability, and gRPC, and the repository also indexes community maintained bundles for technologies the team does not ship itself. Plugin goals cover repackaging, container image building, and ahead of time processing.

Tradeoffs

Opinionated defaults stay cheap only while you agree with them, and the surface here is large enough that overriding one behaviour often means learning a whole subsystem first. The module list is long, so a single upgrade moves many transitive versions at once. Building from source requires JDK 25, well ahead of the runtime baselines it supports. The issue tracker is reserved for bugs and enhancements, usage questions are pushed to Stack Overflow, and dedicated help is sold as a commercial offering. Third party bundles listed in the repository are maintained by other people, not by this team.

How to use it well

This is for teams shipping long lived server side Java or Kotlin services who want health checks, metrics, externalised configuration, and packaging handled by the platform rather than by hand. It earns a place in HTTP APIs, batch jobs, and messaging consumers backed by relational, document, or search stores. It does not cover the browser side, it does not provision or run your infrastructure, and it is a poor fit when you want to wire Spring yourself and see every bean declared explicitly.

Observed

License

Apache 2.0, full text in LICENSE.txt

Language

Java, with the Kotlin JVM plugin applied in core/spring-boot/build.gradle

Build system

Gradle multi-project, wrapper checked in, subprojects enumerated in settings.gradle

Install surface

Maven and Gradle coordinates under org.springframework.boot, plus aggregate starter dependency descriptors

Build tooling

Gradle plugin ids org.springframework.boot and org.springframework.boot.aot; Maven goals include repackage, build-image, and process-aot

Operations interface

Actuator endpoints exposed over HTTP or JMX, metrics through Micrometer

CI platforms

GitHub Actions matrix across Linux and Windows runners in .github/workflows/ci.yml

Contribution gate

Developer Certificate of Origin sign off, with Checkstyle and Spring JavaFormat wired into the build

Support model

Issue tracker limited to bugs and enhancements, usage questions on Stack Overflow, paid enterprise support offered separately