3. What’s New in 2.0?
Prev | Part I. Preface | Next

## 3. What’s New in 2.0?

Spring Cloud Stream introduces a number of new features, enhancements, and changes. The following sections outline the most notable ones:

- Section 3.1, “New Features and Components”
- Section 3.2, “Notable Enhancements”

## 3.1 New Features and Components

- Polling Consumers: Introduction of polled consumers, which lets the application control message processing rates. See “Section 6.3.5, “Using Polled Consumers”” for more details. You can also read this blog post for more details.
- Micrometer Support: Metrics has been switched to use Micrometer. `MeterRegistry` is also provided as a bean so that custom applications can autowire it to capture custom metrics. See “Chapter 14, Metrics Emitter” for more details.
- New Actuator Binding Controls: New actuator binding controls let you both visualize and control the Bindings lifecycle. For more details, see Section 7.6, “Binding visualization and control”.
- Configurable RetryTemplate: Aside from providing properties to configure `RetryTemplate`, we now let you provide your own template, effectively overriding the one provided by the framework. To use it, configure it as a `@Bean` in your application.

## 3.2 Notable Enhancements

This version includes the following notable enhancements:

- Section 3.2.1, “Both Actuator and Web Dependencies Are Now Optional”
- Section 3.2.2, “Content-type Negotiation Improvements”
- Section 3.3, “Notable Deprecations”

### 3.2.1 Both Actuator and Web Dependencies Are Now Optional

This change slims down the footprint of the deployed application in the event neither actuator nor web dependencies required. It also lets you switch between the reactive and conventional web paradigms by manually adding one of the following dependencies.

The following listing shows how to add the conventional web framework:

    <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
    </dependency>

The following listing shows how to add the reactive web framework:

    <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-webflux</artifactId>
    </dependency>

The following list shows how to add the actuator dependency:

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>

### 3.2.2 Content-type Negotiation Improvements

One of the core themes for verion 2.0 is improvements (in both consistency and performance) around content-type negotiation and message conversion. The following summary outlines the notable changes and improvements in this area. See the “Chapter 9, Content Type Negotiation” section for more details. Also this blog post contains more detail.

- All message conversion is now handled only by `MessageConverter` objects.
- We introduced the `@StreamMessageConverter` annotation to provide custom `MessageConverter` objects.
- We introduced the default `Content Type` as `application/json`, which needs to be taken into consideration when migrating 1.3 application or operating in the mixed mode (that is, 1.3 producer → 2.0 consumer).
- Messages with textual payloads and a `contentType` of `text/…​` or `…​/json` are no longer converted to `Message<String>` for cases where the argument type of the provided `MessageHandler` can not be determined (that is, `public void handle(Message<?> message)` or `public void handle(Object payload)`). Furthermore, a strong argument type may not be enough to properly convert messages, so the `contentType` header may be used as a supplement by some `MessageConverters`.

## 3.3 Notable Deprecations

As of version 2.0, the following items have been deprecated:

- Section 3.3.1, “Java Serialization (Java Native and Kryo)”
- Section 3.3.2, “Deprecated Classes and Methods”

### 3.3.1 Java Serialization (Java Native and Kryo)

`JavaSerializationMessageConverter` and `KryoMessageConverter` remain for now. However, we plan to move them out of the core packages and support in the future. The main reason for this deprecation is to flag the issue that type-based, language-specific serialization could cause in distributed environments, where Producers and Consumers may depend on different JVM versions or have different versions of supporting libraries (that is, Kryo). We also wanted to draw the attention to the fact that Consumers and Producers may not even be Java-based, so polyglot style serialization (i.e., JSON) is better suited.

### 3.3.2 Deprecated Classes and Methods

The following is a quick summary of notable deprecations. See the corresponding {spring-cloud-stream-javadoc-current}[javadoc] for more details.

- `SharedChannelRegistry`. Use `SharedBindingTargetRegistry`.
- `Bindings`. Beans qualified by it are already uniquely identified by their type — for example, provided `Source`, `Processor`, or custom bindings:

    public interface Sample {
    	String OUTPUT = "sampleOutput";

    	@Output(Sample.OUTPUT)
    	MessageChannel output();
    }

- `HeaderMode.raw`. Use `none`, `headers` or `embeddedHeaders`
- `ProducerProperties.partitionKeyExtractorClass` in favor of `partitionKeyExtractorName` and `ProducerProperties.partitionSelectorClass` in favor of `partitionSelectorName`. This change ensures that both components are Spring configured and managed and are referenced in a Spring-friendly way.
- `BinderAwareRouterBeanPostProcessor`. While the component remains, it is no longer a `BeanPostProcessor` and will be renamed in the future.
- `BinderProperties.setEnvironment(Properties environment)`. Use `BinderProperties.setEnvironment(Map<String, Object> environment)`.

Prev | Up | Next
2. Quick Start | Home | 4. Introducing Spring Cloud Stream