Rest-client does not write all JSON fields when using both reflection-free serializer and deserializer

[fedinskiy]

Describe the bug

I have an application, with several endpoints. First of them returns POJO class, and the second one accepts the same POJO as input. In both cases POJO is (de)serialized to/from JSON. The first one is called from REST client (in the same app), which makes the result accessible on the third endpoint.
When I enable the new reflection-free (de)serialization, client endpoint returns json with one of the fields set to null. This doesn't happen, when I remove the second endpoint.

Expected behavior

REST client should never lose data

Actual behavior

Original data:
{"author":"Heller","title":"Catch-22"}
Data, copied by REST client:
{"author":null,"title":"Catch-22"}

How to Reproduce?

1. git clone -b client-serialize-field-null git@github.com:fedinskiy/reproducer.git & cd reproducer
2. mvn clean verify This fails
3. mvn clean verify -Dquarkus.rest.jackson.optimization.enable-reflection-free-serializers=false The old version succeeds
4. If method sequel is removed from file src/main/java/io/quarkus/qe/GreetingResource.java, the test succeeds

If we compare these two versions (with and without sequel method), we can find difference in generated classes:

1. mvn clean package -DskipTests -Dquarkus.package.jar.decompiler.enabled=true
2. ls target/decompiler/generated-bytecode/io/quarkus/qe/ | grep quarkusjackson
   The failing version contains deserializer class:

Book$quarkusjacksondeserializer.java
Book$quarkusjacksonserializer.java
SerializedStrings$quarkusjacksonserializer.java

and the working one doesn't

Book$quarkusjacksonserializer.java
SerializedStrings$quarkusjacksonserializer.java

Output of uname -a or ver

6.12.15-200.fc41.x86_64

Output of java -version

21.0.5, vendor: Eclipse Adoptium

Quarkus version or git rev

3.18.4

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)

Additional information

No response

[quarkus-bot]

/cc @cescoffier (rest-client), @geoand (rest-client)

[geoand]

@fedinskiy the Book class you are using is rather odd, in the sense that it missing a setter for author.

The reason it works in Jackson is because it performs reflection and set the value via the field.

So I am personally in favor of closing this as won't fix

[fedinskiy]

@geoand adding a setter helps, thank you, but:

1. This failure is still weird. Why would addition of deserializer affect serializer?
2. There is no warning about that
3. [suggestion for new feature]. It would be great if that new serializer supported @JsonCreator annotation on constructors

[geoand]

This failure is still weird. Why would addition of deserializer affect serializer?

It doesn't

[suggestion for new feature]. It would be great if that new serializer supported @JsonCreator annotation on constructors

This I agree with

[fedinskiy]

It doesn't

But how do you explain the fourth step in reproducer then? This method is not used, and when we add it, the deserializer is created. And after that, the test starts to fail.

This I agree with

What should we do then? Create a new issue?

[geoand]

But how do you explain the fourth step in reproducer then? This method is not used, and when we add it, the deserializer is created. And after that, the test starts to fail.

I looked at the generated code and debugged stuff and I can confidently say that the deserializer is the only problem.

What should we do then? Create a new issue?

Sure, please do that

[gsmet]

I'm not sure about closing this one: the reflection free thing was supposed to be a replacement for standard Jackson and it was supposed to be disabled automatically for specific classes if it couldn't handle some cases.

In this very case, the reflection free thing apparently can't handle things properly so I would expect it to be disabled for the class?

I would very much like to have @mariofusco opinion about this one.

Also, while the case is weird, the fact that the serialization changes when you add some unrelated code is definitely a problem.

[mariofusco]

What should we do then? Create a new issue?

Sure, please do that

The Book class is indeed odd: it has an empty constructor, so the generated deserializer uses it, but the it has no way to set the author (unless using reflection, which is exactly the thing that we want to avoid).

I'm not sure about closing this one: the reflection free thing was supposed to be a replacement for standard Jackson and it was supposed to be disabled automatically for specific classes if it couldn't handle some cases.

I see your point here, but I'm not sure what to do about it. Should we avoid generating the (de)serializers every time we found a bean with a private field without accessor methods? In all honesty this seems a bit too much and I could say that if you have a private field and didn't add the getter/setter for it you don't want that field to be read/written and the generated (de)serializer is simply behaving accordingly (while Jackson's reflection based serialization probably isn't).

[suggestion for new feature]. It would be great if that new serializer supported @JsonCreator annotation on constructors

+1, this seem the only reasonable fix for this use case. Please create a new issue for this and assign it to me.