This version is still in development and is not considered stable yet. For the latest stable version, please use Spring Integration 6.5.2!

What’s New?

For those who are already familiar with Spring Integration, this chapter provides a brief overview of the new features of version 7.0.

If you are interested in the changes and features that were introduced in earlier versions, see the Change History.

What’s New in Spring Integration 7.0?

For more details, see the GitHub Issues that were resolved as part of the 7.0 development process.

In general, the project has been moved to the latest dependency versions. Java 17 is still the baseline, but Java 24 is supported.

General Changes

Junit 4-Based Support Components are deprecated.

The project now leverages JSpecify annotations to expose null-safe APIs and to check the consistency of those nullability declarations with NullAway as part of its build.

The spring-retry dependency, together with all its API usage have been replaced by retry API in Spring Framework Core module. This breaking change is the natural evolution of the whole Spring portfolio. In general, the following references have been migrated:

  • org.springframework.retry.support.RetryTemplate → org.springframework.core.retry.RetryTemplate;

  • org.springframework.retry.RetryPolicy → org.springframework.core.retry.RetryPolicy;

  • org.springframework.retry.RecoveryCallback → org.springframework.integration.core.RecoveryCallback. There is no RecoveryCallback abstraction in the Spring Framework, since regular try..catch on the RetryException is enough. For Spring Integration, the RecoveryCallback makes sense as a dead-letter publisher to an error channel;

  • org.springframework.retry.backoff.BackOffPolicy → org.springframework.util.backoff.BackOff. However, it is not exposed directly as a RetryTemplate options: rather as an internal API backed by the configuration via RetryPolicy.Builder;

  • The RetryContext in AMPQ, JMS and Apache Kafka channel adapters is replaced with an internal AttributeAccessor implementation.

Therefore, the following project classes have suffered breaking changes:

  • AmqpBaseInboundChannelAdapterSpec

  • AmqpBaseInboundGatewaySpec

  • AmqpInboundChannelAdapter

  • AmqpInboundGateway

  • PostgresSubscribableChannel

  • ChannelPublishingJmsMessageListener

  • JmsInboundGatewaySpec

  • JmsMessageDrivenChannelAdapterSpec

  • KafkaInboundGatewaySpec

  • KafkaMessageDrivenChannelAdapterSpec

  • KafkaInboundEndpoint

  • KafkaInboundGateway

  • KafkaMessageDrivenChannelAdapter

The RequestHandlerRetryAdvice was rebuilt to avoid external API as much as possible. For the stateless retry logic, there is just enough to provide a org.springframework.core.retry.RetryPolicy. The stateful retry logic is activated by the Function<Message<?>, Object> stateKeyFunction. The RetryStateGenerator abstraction and its SpelExpressionRetryStateGenerator implementation have been removed due to dependency on the spring-retry API.

See Retry Advice for more information.

New Components

A new DistributedLock interface has been introduced, providing new methods, lock(Duration ttl) and tryLock(long time, TimeUnit unit, Duration ttl), to acquire a lock with a custom time-to-live (TTL). See Distributed Locks for more information.

The Jackson 2 support has been deprecated for removal. Jackson 3 is now the default with new components: JacksonJsonObjectMapper, JacksonPropertyAccessor, JacksonIndexAccessor, and JacksonMessagingUtils. See their Javadocs for more information and deprecated classes for a migration path.

JDBC Changes

The JDBC module now provides a Java DSL API via its dedicated org.springframework.integration.jdbc.dsl.Jdbc factory. The Java DSL for JDBC Components chapter provides more details.

The JdbcLock now supports the feature of customized time-to-live for the lock status data. See JDBC Lock Registry for more information.

Redis Changes

The RedisLock now supports the feature of customized time-to-live for the lock status data. See Redis Lock Registry for more information.

Hazelcast Changes

Previously deprecated classes in the spring-integation-hazelcast module, such as LeaderInitiator, HazelcastMembershipListener, HazelcastLocalInstanceRegistrar and HazelcastLockRegistry, are now removed due to not supported CP-subsystem in Hazelcast library for Open Source.

MQTT Changes

The AbstractMqttMessageDrivenChannelAdapter and ClientManager implementations now expose a quiescentTimeout option which is propagated in their stop() method down to the disconnectForcibly() API of the MQTT Paho clients. See MQTT Support for more information.

Remote Files Support Changes

The AbstractInboundFileSynchronizer now caches a filtered result of the Session.list(remoteDirectory) after slicing by the maxFetchSize. So, later synchronizations deal with the cache only by the maxFetchSize until the cache is exhausted. See Inbound Channel Adapters: Controlling Remote File Fetching for more information.

All the AbstractPersistentAcceptOnceFileListFilter implementations now use a "long file name" for the metadata entry key. Previously, just a file name may cause the metadata overriding problem when the same filter is used for different directories with same file names. For example, the RotatingServerAdvice may switch to directories based on the timestamp, but files are placed there with the same name according to business logic. See Remote Persistent File List Filters for more information.

Null Safety

Updated the codebase to use JSpecify and NullAway, adding a comprehensive null safety implementation that uses @NullMarked annotations to default all types to non-null at the package level and @Nullable annotations to explicitly mark types that can be null. See Null Safety for more information.