46546 added a complete support for the Kotlin Serialization library: auto-configuring a Json bean, supporting configuration properties, and processing the relevant HttpMessageConverter as one of the available options for JSON. This includes the support for the spring.http.converters.preferred-json-mapper property.

While discussing this support with other team members, we think we need to revisit this arrangement.

The Kotlin Serialization library is involved when: 1. types are annotated with @Serializable 2. a compiler plugin has been configured and has generated serializer classes 3. the Kotlin Serialization library is present at runtime

As seen in https://github.com/spring-projects/spring-boot/issues/24238, there are many cases where applications depend on libraries that themselves ship serializable classes and bring the Kotlin Serialization library as a transitive dependency. This means 1) 2) and 3) are verified and the Spring support is active.

On the other hand, there are many Java types that do not fit those conditions (typically, types returned by Actuator endpoints, or ProblemDetail support in Framework) and where Jackson is still very much required. This means that in general, the KotlinSerializationHttpMessageConverter should not be considered as a JSON variant like others, but instead configured ahead of the main JSON converter. If KotlinSerializationHttpMessageConverter cannot serialize/deserialize, the main JSON converter will be used as a fallback.

Now that the Spring Boot codebase has been modularized and that we have a dedicated "spring-boot-kotlin-serialization" module, bringing this dependency on the classpath is a much stronger signal for applications.

In this issue, we should: * remove the kotlin-serialization option from spring.http.converters.preferred-json-mapper * configure the kotlin serialization http message converter ahead of the JSON ones