Description
The following happens when working with a RabbitMQ message broker.
Investigating an exception thrown from within the deep bowels of Spring Cloud Stream I have come across a weird change between 4.1.2 and 4.1.3.
The JSON serialization format of any Date/Time related class has changed from a ISO 8601-like String to a unix timestamp.
The following examples are for an hypothetical ts property of different Java types and the values are directly copied from the message received in the queue.
Examples for 4.1.2 (in 2023.0.2):
j.u.Date:"ts": "2024-07-29T09:21:40.206+00:00"j.t.Instant:"ts": "2024-07-29T09:20:15.002750Z"j.t.ZonedDateTime:"ts": "2024-07-28T14:46:27.0000005+02:00"
Examples for 4.1.3 (in 2023.0.3):
j.u.Date:"ts": 1722253394807j.t.Instant:"ts": 1722253298.240253000j.t.ZonedDateTime:"ts": 1722170787.000000500
Another peculiar choice is that j.u.Date is now serialized as milliseconds while java.time classes as seconds with a decimal part.
The code I used to generate a message is the following:
// Object containing a few time-related properties
var domObj = new ObjectWithDates();
Message<ObjectWithDates> payload = MessageBuilder.withPayload(domObj).build();
// Simple output binding configured in application.yml
// StreamBridge is the default one
streamBridge.send("testError-out-0", payload);The sample project I used to investigate uses Java 21 and has the following dependencies:
implementation(platform("org.springframework.boot:spring-boot-dependencies:3.3.2"))
implementation("org.springframework.boot:spring-boot-starter-web")
implementation("org.springframework.boot:spring-boot-starter-actuator")
implementation(platform("org.springframework.cloud:spring-cloud-dependencies:2023.0.2")) // or 2023.0.3
implementation("org.springframework.cloud:spring-cloud-starter-stream-rabbit")