Spring Forward: The Architecture-Defining Release Cycle of 2025-2026
How Spring Framework 7,
Boot 4, Integration 7, Batch 6, and AI 2.0 are reshaping the way enterprise
systems are designed, built, and operated — and what every tech lead needs to
know before their next architecture review.
The Spring ecosystem has
never moved faster. Across six major projects — Framework, Boot, Integration,
Batch, and AI — the teams at Broadcom have delivered what I consider the most
consequential release cycle in the platform's history. This is not a changelog
summary. It is an architectural assessment of what these changes mean for the
systems we design, the teams we lead, and the technical decisions we will have
to defend in production.
📊 Figure 1 — The
Spring Platform at a Glance (2025-2026)
|
Project |
Latest Version |
Headline Theme |
Key Innovations |
|
🏗️ Spring
Framework |
7.0 |
Correct-by-Default |
API Versioning, JSpecify
null safety, BeanRegistrar, Native Resilience |
|
🚀 Spring Boot |
4.0 |
Disciplined Modernization |
Modular Auto-Config,
Declarative HTTP Clients, Jackson 3, Jakarta EE 11 |
|
🔗 Spring
Integration |
7.0 |
Distributed-First |
TTL-aware
DistributedLock, AMQP 1.0, JDBC DSL, JSON Message Store |
|
⚙️ Spring Batch |
6.0 |
Observable at Scale |
Producer-Consumer
Concurrency, JFR Observability, MongoDB Repository |
|
🤖 Spring AI |
2.0 |
AI as a First-Class
Citizen |
MCP Core Integration,
Prompt Caching (90% cost cut), Recursive Advisors |
Spring Framework 7:
The Core Gets Sharper
Every generation of enterprise Java has a moment where the plumbing
catches up to the philosophy. Spring Framework 7 is that moment for the modern
cloud-native paradigm. Built on a Jakarta EE 11 baseline and requiring JDK 17
minimum (with JDK 25 as the recommended target), Framework 7 is a deliberate
and opinionated statement about what professional Java development should look
like in 2025 and beyond.
The feature I find most architecturally significant is first-class
API versioning. Before Framework 7, versioning REST APIs was a convention
war — you chose between URI paths, custom headers, media types, or query
parameters, then wired it all by hand. Framework 7 makes versioning a native
concept in @RequestMapping:
@RequestMapping("/api/products")
public class ProductController {
@RequestMapping(value = "/search", version = "1")
public List<ProductV1> searchV1(@RequestParam String query) { ...
}
@RequestMapping(value = "/search", version = "2")
public ProductSearchResponseV2 searchV2(@RequestParam String query,
@RequestParam(defaultValue = "10") int limit) { ... }
}
The framework supports path, header, query parameter, and media type
versioning strategies, configurable through spring.mvc.apiversion.* properties, and includes built-in deprecation handling that complies
with RFC 9745. Both RestClient and WebClient use the new ApiVersionInserter on the client side. For teams building public APIs or managing
internal service contracts across long-lived microservices, this alone
justifies the upgrade conversation ( Spring Boot 4 and Spring AI 2.0: The New Java AI Stack - Medium, 2026 ; Spring Boot 4 and Spring Framework 7: Key Features and Changes, 2025 ).
Null safety via JSpecify is the second
architectural win. The framework has migrated away from the inconsistent
JSR-305 and JetBrains annotation mix to JSpecify's standardized @Nullable and @NonNull model. Kotlin 2 translates these automatically into Kotlin nullability
contracts, and static analysis tools such as NullAway can enforce them at
compile time ( Spring Boot 4 and Spring Framework 7: Key Features and Changes, 2025
). This is not a cosmetic change — it shifts null-related errors from
runtime exceptions to build failures, which is the correct direction for any
system at scale.
The new BeanRegistrar contract deserves attention from anyone who has fought with
Spring's reflection-heavy bean registration in AOT or native image scenarios.
It allows purely programmatic, condition-driven bean registration without the
overhead of classpath scanning, a genuine improvement for GraalVM native builds
and modular application architectures ( Spring Boot 4 and Spring Framework 7: Key Features and Changes, 2025
).
Framework 7 also introduces native resilience annotations — @Retryable, @ConcurrencyLimit, and @EnableResilientMethods — built directly into spring-context, no Resilience4j dependency required for common use cases ( Spring Boot 4 and Spring Framework 7: Key Features and Changes, 2025
). For teams building AI-adjacent applications where model API calls are
inherently flaky, having retry with exponential back-off and jitter as a
framework primitive is practically significant. The new JmsClient and the enhanced JdbcClient complete the picture of a framework that has internalized the lessons
of a decade of community feedback ( Spring Boot 4 and Spring Framework 7: Key Features and Changes, 2025
).
🏗️ Figure 2 — Spring Framework 7: Four Pillars of Modernization
┌─────────────────────────────────────────────────────────────────────┐
│ SPRING FRAMEWORK 7.0 │
├──────────────────┬─────────────────┬─────────────────┬─────────────┤
│
API │ Null
│ Resilience │
Modern │
│
Versioning │ Safety
│ Native │
Clients │
│ │ │ │ │
│
@RequestMapping │ JSpecify + │
@Retryable │ JmsClient
│
│
(version="1") │ NullAway
│ @Concurrency │
JdbcClient │
│ RFC
9745 │ compile-time
│ Limit │
RestTest- │
│
Header/Path/ │ null checks
│ No Resilience │
Client │
│
MediaType/Query │
Kotlin-native │ 4j needed
│ Stream I/O │
├──────────────────┴─────────────────┴─────────────────┴─────────────┤
│
Foundation: Jakarta EE 11 · JDK 17-25 · GraalVM 24 │
│
BeanRegistrar (AOT-friendly) · Kotlin 2.2 │
└─────────────────────────────────────────────────────────────────────┘
Spring Boot 4: A
Disciplined Modernization
Spring Boot 4, which shipped in November 2025, is not a revolutionary
rewrite. Architects who expect a paradigm shift will be disappointed. What they
will find instead is a disciplined, debt-reduction release that cleans up
accumulated API surface, aligns with Jakarta EE 11, and introduces several
features with direct impact on operational and developer experience ( Spring Boot 4 and Spring Framework 7: Key Features and Changes, 2025
).
The highest-impact platform decision is modularized
auto-configuration. The monolithic spring-boot-autoconfigure JAR has been decomposed into technology-specific modules — spring-boot-autoconfigure-data-jpa, spring-boot-autoconfigure-web, and so on. For large applications, this directly reduces classpath
scanning overhead and improves startup time, a benefit that compounds inside
containerized environments where cold start latency matters ( Spring Boot 4 and Spring AI 2.0: The New Java AI Stack - Medium, 2026
).
Declarative HTTP service clients are now
native to Spring Boot — Feign-style interface-driven clients generated by the
framework itself. The new HTTP Interface
Groups feature allows applications to configure
many HTTP clients at once, sharing a single RestClient, dramatically reducing wiring boilerplate in microservice
architectures with dozens of service-to-service calls ( Spring Boot 4 and Spring AI 2.0: The New Java AI Stack - Medium, 2026
):
@HttpExchange("/api/users")
public interface UserClient {
@GetExchange("/{id}")
User
getUser(@PathVariable Long id);
@PostExchange
User
createUser(@RequestBody User user);
}
The Jackson 3 migration is a breaking change that deserves
explicit architectural attention. Package relocation from com.fasterxml.jackson to tools.jackson, the replacement of ObjectMapper with an immutable JsonMapper, and the switch to alphabetical property sorting and ISO-8601 dates as
defaults — all of these will surface in integration tests before they surface
in production, which is precisely why the migration path must be planned, not
reacted to ( Spring Boot 4 and Spring AI 2.0: The New Java AI Stack - Medium, 2026 ; Spring Boot 4 and Spring Framework 7: Key Features and Changes, 2025 ).
On the platform side, Spring Boot 4 targets GraalVM 24 for
native image builds, provides full Kotlin 2.2 support with smoother
coroutine integration, and aligns with Jakarta EE 11 (Servlet 6.1, JPA
3.2, Hibernate ORM 7.0, Bean Validation 3.1) ( Spring Boot 4 and Spring Framework 7: Key Features and Changes, 2025
). Virtual threads, enabled via spring.threads.virtual.enabled=true on JDK 25, make structured concurrency a configuration choice rather
than an architectural overhaul ( Spring Boot 4 and Spring AI 2.0: The New Java AI Stack - Medium, 2026
).
🚀 Figure 3 — Spring Boot 4: Platform Stack
╔══════════════════════════════════════════════════════════════╗
║ SPRING BOOT 4 -
PLATFORM STACK ║
╠══════════════════════════════════════════════════════════════╣
║ APPLICATION LAYER ║
║ ┌──────────────────────┐ ┌────────────────────────────┐ ║
║ │
@HttpExchange │ │
@Retryable (exp. backoff) │ ║
║ │
Declarative HTTP │ │
@ConcurrencyLimit │ ║
║ │
Interface Groups │ │
Built-in — no Resilience4j│ ║
║ └──────────────────────┘ └────────────────────────────┘ ║
╠══════════════════════════════════════════════════════════════╣
║ FRAMEWORK LAYER ║
║ ┌───────────────┐ ┌─────────────┐ ┌───────────────────┐ ║
║ │
Modularized │ │
Jackson 3 │ │ API
Versioning │ ║
║ │
Auto-Config │ │
JsonMapper │ │ (Spring FW 7) │ ║
║ │
(per-tech │ │
immutable │ │
Path/Header/ │ ║
║ │ JAR
split) │
│ ISO-8601 │
│ MediaType/Query │ ║
║ └───────────────┘ └─────────────┘ └───────────────────┘ ║
╠══════════════════════════════════════════════════════════════╣
║ PLATFORM BASELINE ║
║ Jakarta EE 11 | JDK
25+ |
GraalVM 24 | Kotlin 2.2
║
║ Servlet 6.1 |
JPA 3.2 | Hibernate 7 |
OpenTelemetry║
║ Virtual Threads:
spring.threads.virtual.enabled=true
║
╚══════════════════════════════════════════════════════════════╝
Spring Integration
7: Distributed-First, Observable by Default
Spring Integration does not generate the same conference-talk
enthusiasm as Spring AI. But for architects designing event-driven systems,
integration pipelines, or anything touching enterprise messaging, version 7
contains changes that will meaningfully improve operational and correctness
guarantees at runtime.
The most architecturally consequential addition is the new DistributedLock interface with TTL-aware methods: lock(Duration ttl) and tryLock(long time,
TimeUnit unit, Duration ttl). Both the JdbcLock and RedisLock registries implement this interface, allowing operators to control
lock lifetime without risking permanent lock acquisition after a node failure ( What’s New? :: Spring Integration, n.d. ). In distributed scheduled processing scenarios — think billing runs,
inventory reconciliation, or any pattern where idempotency under failure
matters — this replaces a class of error-prone, hand-rolled solutions.
RabbitMQ AMQP 1.0 support arrives in the spring-integration-amqp module, a significant protocol modernization. AMQP 1.0 is the
standardized version of the protocol, interoperable across Azure Service Bus,
ActiveMQ Artemis, and Amazon MQ. Teams migrating away from proprietary broker
lock-in now have a first-class integration path within the Spring model ( What’s New? :: Spring Integration, n.d. ).
The JDBC module now exposes a Java DSL API via its org.springframework.integration.jdbc.dsl.Jdbc factory, bringing the JDBC channel adapter into parity with the rest
of the DSL-based configuration surface. Combined with the JSON serialization
support in JdbcChannelMessageStore — using JSONB, JSON, TEXT, or CLOB column types as alternatives to
binary serialization — this opens the door to message store contents that are
inspectable and queryable by operators without custom deserialization tooling ( What’s New? :: Spring Integration, n.d. ).
The full migration to JSpecify and NullAway across the codebase
is consistent with Framework 7's direction and means null-safety contracts are
now enforced at build time across the entire integration surface ( What’s New? :: Spring Integration, n.d. ). The retirement of spring-retry in favor of the native retry API in spring-core is a breaking change with a clear migration path, and it simplifies
the dependency graph for applications that already carry Spring Framework ( What’s New? :: Spring Integration, n.d. ).
🔗 Figure 4 — Spring Integration 7: Distributed Event-Driven
Message Flow
┌───────────────────────────────────────────────────────────────────┐
│ SPRING INTEGRATION 7 -
MESSAGE TOPOLOGY │
│
│
│ INBOUND ADAPTERS CHANNELS OUTBOUND ADAPTERS │
│
│
│ ┌────────────────┐ ┌──────────────────┐ ┌───────────────┐ │
│ │
RabbitMQ │ │
Message Channel │ │
JDBC DSL │ │
│ │ AMQP
1.0 ───▶│ │
JdbcMessageStore │──▶│
Adapters │ │
│ │
(Azure SB, │ │
(JSON / JSONB) │ └───────────────┘ │
│ │
ActiveMQ, │ └────────┬──────────┘ ┌───────────────┐ │
│ │
Amazon MQ) │ │ │ HTTP / WS /
│ │
│ └────────────────┘ ┌────────▼──────────┐ │
SFTP / MQTT │ │
│ ┌────────────────┐ │
Handlers & │──▶│ │ │
│ │ File
/ SFTP │───▶│ Advisors │
└───────────────┘ │
│ │
(SpEL dirs) │ │
(retry, logging) │
│
│ └────────────────┘ └────────┬──────────┘ │
│ │ │
│
┌──────────────────▼──────────────────────┐ │
│ │ DistributedLock (TTL-aware) │ │
│ │
JdbcLock · RedisLock · lock(Duration)
│ │
│ │ Prevents duplicate execution on
failure│ │
│
└─────────────────────────────────────────┘ │
│
│
│ NullAway enforced at build time · JSpecify
null contracts │
│ spring-retry replaced by native Spring
Framework retry API │
└───────────────────────────────────────────────────────────────────┘
Spring Batch 5.2
and 6.0: Scale, Observability, and Architectural Breadth
Spring Batch has historically been the most underappreciated project in
the Spring portfolio. The combination of 5.2 and the forthcoming 6.0 release
demonstrates that the team understands exactly where enterprise batch
processing needs to evolve: toward broader persistence options, better
concurrency models, and deeper observability.
MongoDB job repository support in 5.2 is the
headline for NoSQL-native platforms. This is the first non-relational job
repository implementation in the project's history. It is backed by Spring Data
MongoDB, requires MongoDB 4 or later, and provides the same job metadata
semantics as the relational implementation. For teams running on document-store
infrastructure — or those who want to avoid relational database provisioning
for batch metadata — this removes a long-standing architectural friction ( What’s New in Spring Batch 5.2, n.d. ).
The CompositeItemReader addresses a pattern that every serious batch architect has implemented
from scratch at least once: reading sequentially from multiple heterogeneous
sources with the same output type. Combined with the new BlockingQueueItemReader and BlockingQueueItemWriter, which implement the Staged Event-Driven Architecture (SEDA) pattern
directly within the batch framework, complex multi-stage pipelines can now be
designed as first-class batch constructs rather than bespoke thread
coordination code ( What’s New in Spring Batch 5.2, n.d. ).
The new adapters for java.util.function APIs — SupplierItemReader, ConsumerItemWriter, and PredicateFilteringItemProcessor — bring the functional programming model into the batch processing
space. Lambda-driven batch logic is no longer second-class; it integrates
naturally with the item-oriented processing model ( What’s New in Spring Batch 5.2, n.d. ).
Spring Batch 6.0 introduces what I consider the most important batch
engineering improvement in years: a redesigned concurrency model based on
the producer-consumer pattern. The previous parallel iteration approach
carried confusing transaction semantics and was prone to throttling and
backpressure issues due to the overhead of state synchronization across
multiple levels. The new model uses a bounded internal queue between a single
producer thread and multiple consumer threads. Items enter the queue as soon as
they are ready; consumers take items as soon as they are available; and once a
chunk is ready to be written, the producer pauses until the write completes
before resuming. The result is a simpler mental model, better performance, and
more predictable transaction boundaries ( Spring Batch 6.0.0-M3 and 5.2.3 Are Out!, 2025 ).
⚙️ Figure 5 — Spring Batch 6.0: Old vs. New Concurrency Model
BEFORE - Parallel Iteration (confusing transaction
semantics)
┌──────────┐ ┌──────────┐ ┌──────────┐
│
Thread 1 │ │ Thread 2 │ │ Thread N │ All threads contend
│
Read │ │ Read
│ │ Read │
for shared state.
│
Process │ │ Process
│ │ Process │
Backpressure unclear.
│
Write │ │ Write
│ │ Write │
Poor performance.
└──────────┘ └──────────┘ └──────────┘
─────────────────────────────────────────────────────────────────
AFTER - Producer-Consumer (clear boundaries, fast)
┌───────────────────────────────────────────────────────────────┐
│ PRODUCER THREAD │
│ Read Items ──▶ Process ──▶ Enqueue │
│ (pauses when chunk is ready to write, then
resumes) │
└─────────────────────────────────────────────┬────────────────┘
│
┌──────────────────▼─────────────────┐
│ Bounded Internal Queue │
└──────┬──────────────────┬──────────┘
┌───────────────┐
┌─────────────▼────┐
┌─────────▼──────────┐
│ Consumer 1
│ │ Consumer 2 │
│ Consumer N │
│ Dequeue +
│ │ Dequeue + │
│ Dequeue + │
│ Write chunk
│ │ Write chunk │
│ Write chunk │
└───────────────┘
└──────────────────┘
└────────────────────┘
Result:
Predictable transactions · No backpressure surprises · Faster
Plus:
JFR events (job, step, read, write, tx) · StoppableStep interface
The introduction of Java Flight Recorder (JFR) observability in
6.0 is equally significant. JFR events now cover job and step executions, item
reads and writes, and transaction boundaries — all with the minimal overhead
that makes JFR suitable for production profiling. This complements the existing
Micrometer metrics integration and gives operational teams a two-level
observability story: metrics for dashboards and alerting, JFR for deep forensic
investigation ( Spring Batch 6.0.0-M3 and 5.2.3 Are Out!, 2025 ). The new StoppableStep interface completes the external control surface, allowing
custom step implementations to respond gracefully to JobOperator#stop signals — a gap that forced ugly workarounds in any batch system
requiring graceful shutdown under orchestration ( Spring Batch 6.0.0-M3 and 5.2.3 Are Out!, 2025 ).
Spring AI: From
Integration Library to Application Platform
Spring AI's trajectory from an experimental integration layer to a
production-grade AI application platform has been the fastest evolution I have
observed in the Spring ecosystem. Spring AI 1.1 GA delivered over 850
improvements, bug fixes, and documentation updates. Spring AI 2.0, currently in
milestone releases and targeting Spring Boot 4, completes the transformation.
The centerpiece of Spring AI 1.1 is Model Context Protocol (MCP)
integration. MCP represents the most significant feature improvement of the
1.1 cycle, providing Spring Boot auto-configuration and a comprehensive
annotation-based programming model for connecting AI models to external tools,
resources, and services ( Spring AI 1.1 GA Released, 2025 ). The framework supports multiple transport options (Streamable HTTP as
the modern default, SSE for backward compatibility, stdio for local process
tooling), and Spring Boot auto-configuration spans WebFlux, WebMVC, and Servlet
environments ( Spring AI 1.1 GA Released, 2025 ). Security integration covers OAuth2 patterns for securing MCP servers.
In architectural terms, MCP transforms a Spring application from a passive AI
consumer into an active participant in an AI tool ecosystem.
Prompt caching for Anthropic Claude and AWS Bedrock may be the single highest-ROI feature for teams already running AI
workloads in production. Spring AI 1.1 adds support for five cache strategies
with 5-minute and 1-hour TTL options, reducing API costs by up to 90%
while improving response times for repeated or structurally similar prompts ( Spring AI 1.1 GA Released, 2025 ). For any system calling large language models at volume, the
difference between cached and uncached inference is the difference between a
viable unit economics model and one that requires constant justification to
finance teams.
The recursive advisor pattern enables advisors to call other
advisors in chains, creating sophisticated multi-step AI workflows. Two
built-in recursive advisor implementations provide pre-configured patterns for
common use cases, with configurable observations for monitoring and debugging.
This unlocks self-improving AI agents that refine their own outputs through
iterative processing and enables the LLM-as-a-Judge evaluation pattern — a
powerful approach for automated quality assurance in AI pipelines ( Spring AI 1.1 GA Released, 2025 ).
Native reasoning model support across multiple
providers gives teams access to deliberative AI capabilities through a
consistent Spring abstraction. The ReasoningContent API enables applications to inspect and utilize the model's internal
reasoning process, not just its final output — a capability that is essential
for auditability in regulated environments and for debugging unexpected model
behavior ( Spring AI 1.1 GA Released, 2025 ).
Spring AI 2.0 completes the MCP integration by merging community MCP
support into core, elevating MCP annotations to first-class status, and moving
Spring-specific MCP transport implementations from the MCP Java SDK into the
Spring AI project itself. A Spring Boot application can simultaneously act as
both an MCP client (consuming external tools, database access, third-party
APIs) and an MCP server (exposing its own business logic as MCP-compliant
tools) ( Spring Boot 4 and Spring AI 2.0: The New Java AI Stack - Medium, 2026
). With support for over 20 model providers — OpenAI, Anthropic, Google
Vertex AI, AWS Bedrock, Azure OpenAI, Ollama, Mistral, and more — the
abstraction layer makes provider switching a configuration change, not a code
change.
🤖 Figure 6 — Spring AI 2.0: Full Application Platform
Architecture
┌──────────────────────────────────────────────────────────────────┐
│ SPRING AI 2.0 -
PLATFORM VIEW │
│
│
│ Your Spring Boot 4 Application │
│
┌────────────────────────────────────────────────────────────┐ │
│ │
ADVISORS API PIPELINE (composable
middleware) │ │
│ │
┌───────────┐ ┌───────────┐ ┌──────────────┐ ┌────────┐ │ │
│ │
│ RAG │
│ Memory │ │
Guardrails │ │ Model │
│ │
│ │
│ Advisor │▶│ Advisor │▶│ /
Logging / │▶│ Call │ │ │
│ │ │
(vector │ │ (history) │ │ Token budget│ │ │
│ │
│ │
│ store) │ │
│ │ │ │ │
│ │
│ │
└───────────┘ └───────────┘ └──────────────┘ └────────┘ │ │
│ │
Recursive Advisors: self-refine · LLM-as-a-Judge eval │ │
│
└────────────────────────────────────────────────────────────┘ │
│ │
│ MODEL CONTEXT PROTOCOL (MCP) -
First-class in AI 2.0 Core │
│ ┌──────────────────────┐ ┌─────────────────────────────┐ │
│ │ MCP
CLIENT │ │
MCP SERVER │ │
│ │
Filesystem tools │ │
Exposes @Tool/@Resource │ │
│ │
Database access │ │
beans via Streamable HTTP │ │
│ │
3rd-party APIs │ │
SSE · stdio · OAuth2 │ │
│ └──────────────────────┘ └─────────────────────────────┘ │
│
│
│ PROMPT CACHING - Up
to 90% cost reduction │
│ Anthropic Claude: 5-min and 1-hour TTL | 5
strategies │
│ AWS Bedrock: Claude + Nova model
caching | Auto-managed │
│
│
│ 20+ MODEL PROVIDERS - swap
via config, not code │
│ OpenAI · Anthropic · Google Gemini · AWS
Bedrock · Azure OpenAI │
│ Ollama · Mistral · ElevenLabs TTS ·
HuggingFace · and more... │
└──────────────────────────────────────────────────────────────────┘
The Architectural
Synthesis: What This Means for the Systems We Build
Stepping back from the feature inventory, there are three architectural
themes that cut across all of these releases and deserve deliberate attention
from anyone leading technical decisions in 2025 and 2026.
First, the framework is becoming increasingly correct-by-default. JSpecify null safety in Framework 7 and Integration 7, the built-in
resilience annotations, the TTL-aware distributed locks — these are not
convenience features. They are the framework absorbing hard-won operational
lessons and making the correct behavior the path of least resistance. Teams
that embrace these defaults will ship more reliable systems with less bespoke
infrastructure code.
Second, observability is no longer an afterthought. JFR in Spring Batch, Micrometer enhancements in Spring AI,
OpenTelemetry integration in Spring Boot 4 — observability is now a design-time
consideration at the framework level, not a library bolted on after the first
production incident. Architects should treat this as an opportunity to
establish observability contracts as part of their system design rather than
their incident response.
Third, AI is not a separate track. Spring AI
2.0 is architecturally integrated with Spring Boot 4, Spring Framework 7, and
the Advisors API that composes naturally with Spring's dependency injection
model. The implication is that AI capabilities are becoming first-class
components in enterprise Spring applications, subject to the same patterns of
configuration, lifecycle management, resilience, and observability as any other
component. The teams that will build the best AI-augmented systems are not
those learning AI frameworks in isolation — they are the ones who understand
how AI capabilities integrate with the broader application architecture.
The Spring ecosystem has always rewarded architects who think
holistically across the platform. The 2025-2026 release cycle makes that
holistic thinking more productive than ever.
References
Spring AI 1.1 GA Released. (2025).
https://spring.io/blog/2025/11/12/spring-ai-1-1-GA-released
Spring Batch 6.0.0-M3 and 5.2.3 are out!
(2025). https://spring.io/blog/2025/09/17/spring-batch-6-0-0-m3-5-2-3-released
Spring Boot 4 and Spring AI 2.0: The New Java AI Stack - Medium. (2026).
https://medium.com/@chrisvanbreeden/spring-boot-4-and-spring-ai-2-0-the-new-java-ai-stack-58e9577e7919
Spring Boot 4 and Spring Framework 7: Key Features and Changes. (2025).
https://loiane.com/2025/08/spring-boot-4-spring-framework-7-key-features/
What’s new in Spring Batch 5.2. (n.d.).
https://www.spring-doc.cn/spring-batch/5.2.4/whatsnew.en.html
What’s New? :: Spring Integration. (n.d.).
https://docs.spring.io/spring-integration/reference/whats-new.html
Comments
Post a Comment