The Spring Boot team recently released v2.2.0 M1, the first milestone release of Spring Boot 2.2. It includes performance and memory improvements, Kubernetes-detection, and third-party library updates. Over 140 issues were resolved with this release.
Starting with this release, JMX is now disabled by default. Brian Clozel from the Spring team notes,
“This feature doesn’t seem to be widely used and takes a significant amount of resources so we’re reconsidering this default for the 2.2 line.”
Other startup performance improvements include a new feature to provide global lazy initialization, removal of redundant JPA scanning, faster binding of large configuration files, and more efficient bean creation and injection.
Global lazy initialization (enabled with spring.main.lazy.initialization) is a new and noteworthy feature introduced in 2.2 that significantly reduces startup times by delaying all bean creation until use. It does, however, come with trade offs. Initial requests for HTTP resources may have increased latency as any required beans are initialized. Subsequent requests are obviously unaffected. Another, potentially more risky trade off is that any bean-related, wiring, or dependency errors that would have normally occurred on startup will be delayed until later.
Startup performance is also improved by disabling other JPA scanners (e.g. Hibernate). Spring Boot already provides its own JPA scanning so all other scanners are redundant and only add to the time it takes to start an application.
Binding of large configuration files, a process which must happen on startup, is now significantly faster. This seemed to be a much welcomed change for users as one Reddit user stated that with previous versions, “… loading a YAML file on startup (roughly 5000 properties) would take 10 seconds on my i7.”
Since bean creation and injection have direct implications on startup times and memory usage, Spring Boot is now smarter about which beans it chooses to create and inject. Particularly, beans related to Spring Boot actuator endpoints are now only created if the actuator is both enabled and exposed (e.g. via HTTP). It’s also smarter about its use of beans in autoconfigurations. If only part of an autoconfiguration uses a bean but its always injected into the constructor, then it’s unnecessarily created and injected for the other parts that don’t even use it. Specifically, autoconfigurations are now more precise about their usage of dependent beans.
The @ConditionalOnCloudPlatform annotation received an update with the ability to detect when an application is running on a Kubernetes platform. This makes it easy for the user or other frameworks to conditionally configure functionality or implementations that only apply to Kubernetes.
On the dependency front, AssertJ, Mockito, Kafka, Spring HATEOAS, and Spring Data were a few of the notable third-party libraries upgraded. Several other dependencies were also upgraded.
There were also changes to Java EE dependencies. All Java EE dependencies were replaced with the equivalent Jakarta EE dependencies. This is part of the larger migration from Java EE to Jakarta EE, the new name for EE under the Eclipse Foundation.
Milestone releases mark important points of the development cycle for Spring Boot releases. They indicate that the release is solidifying and the majority of major bugs and issues have been resolved. They typically foreshadow that a final release is imminent and mainly serve to fine-tune and polish any remaining issues. Past releases in the 2.0 line have had between four and seven milestone releases.