Who contributed to Spring on July 15, 2026?

8 developers shipped this update, including Ns, Stéphane Nicoll, dhruv-15-03, Jens Schauder, dependabot, Soby Chacko, 박하민, and BoykoAlex.

What were the notable Spring updates?

Lazily resolve JPA fallback bootstrap executor, JpaBaseConfiguration#entityManagerConfiguration can cause a dependency loop on beans declaring AsyncTaskExecutor, and Avoid removing application-managed JUL bridge handler.

Jul 15, 2026

$ the-wire · showcase

SPRING BOOT FIXES LAZY INITIALIZATION TRAP THAT BREAKS JPA APPS

By RepoJournal · Filed 07:01 UTC on July 15, 2026 · About Spring · Composed from the cited sources · methodology

8 people shipped this

Ns @ns3154 2 cited

Stéphane Nicoll @snicoll 2 cited

dhruv-15-03 @dhruv-15-03 1 cited

dependabot @dependabot 1 cited

박하민 @cfcromn 1 cited

BoykoAlex @BoykoAlex 1 cited

Jens Schauder @schauder

Soby Chacko @sobychacko

Spring Boot patched a critical dependency loop where JPA configuration was forcing early instantiation of every AsyncTaskExecutor bean in your app, even when background bootstrapping wasn't enabled.

In brief

Spring Boot fixed a circular dependency trap in JpaBaseConfiguration that fired when beans declared AsyncTaskExecutor. The fallback executor now resolves lazily instead of eagerly. One less mystery bean conflict.
JPA bootstrap executor resolution got lazy. This small shift prevents Spring Boot from forcing eager instantiation of fallback executors, which was breaking app startup when custom async beans were present.
Spring Boot stopped yanking out the application-managed JUL bridge handler during shutdown. Seemed harmless, but it was breaking logging behavior for apps that manage their own java.util.logging setup.
Spring Kafka tightened up the Kafka send overload nullability contract. Less guessing about which parameters can actually be null at runtime.

The entityManagerFactoryBuilder was eagerly resolving a Map of AsyncTaskExecutor beans to pick a fallback executor for background JPA work [1] [2]. This forced initialization of every executor in the container upfront, creating circular dependency nightmares when those executors depended on EntityManager itself. The fix lazily resolves the executor only when background bootstrapping is actually in use, a common pattern that should have been there from day one. Spring Boot also tightened up logging system cleanup [3], preventing the framework from removing JUL bridge handlers that applications had installed themselves. Meanwhile, Spring Security bumped Kotlin to 2.4.10 [6], Spring Kafka fixed nullability contracts on its send overloads to match actual behavior [7], and Spring Tools ripped out the deprecated jdk_tools bundle in favor of VM agent JMX URLs for local debugging [8]. Gradle 9.6.1 landed across the stack [4] [5] with some new deprecation warnings suppressed.

Action items

→ Update Spring Boot immediately if you use JPA with custom AsyncTaskExecutor beans spring-projects/spring-boot [immediate]
→ Upgrade Spring Kafka if you're relying on nullability contracts for send operations spring-projects/spring-kafka [plan]
→ Update Spring Tools if you use local JMX debugging in your IDE spring-projects/spring-tools [plan]

References

[1] Lazily resolve JPA fallback bootstrap executor spring-projects/spring-boot ↗
[2] JpaBaseConfiguration#entityManagerConfiguration can cause a dependency loop on beans declaring AsyncTaskExecutor ↗ spring-projects/spring-boot
[3] Avoid removing application-managed JUL bridge handler spring-projects/spring-boot ↗
[4] Polish "Upgrade to Gradle 9.6.1" ↗ spring-projects/spring-boot
[5] Upgrade to Gradle 9.6.1 spring-projects/spring-boot ↗
[6] Bump org-jetbrains-kotlin from 2.4.0 to 2.4.10 ↗ spring-projects/spring-security
[7] GH-4524: Fix Kafka send overload nullability ↗ spring-projects/spring-kafka
[8] Use VM agent JMX URL for local processes. Remove jdk_tools bundle ↗ spring-projects/spring-tools