FasterXML / jackson-databind

General data-binding package for Jackson (2.x): works on streaming API (core) implementation(s)
Apache License 2.0
3.52k stars 1.38k forks source link

Inconsistent behavior on deserialization of immutable classes vs records with @JsonIdentityInfo #3307

Open javster101 opened 2 years ago

javster101 commented 2 years ago

Describe the bug When using @JsonIdentityInfo, Jackson deserializes an immutable class fine but the equivalent record does not.

Version information Jackson 2.13.0

To Reproduce I have a simple immutable class defined as follows:

@JsonSerialize
@JsonAutoDetect(fieldVisibility = JsonAutoDetect.Visibility.ANY)
@JsonIdentityInfo(generator = ObjectIdGenerators.PropertyGenerator.class, property = "name", scope = ProjectResource.class)
 public static final class ProjectResource {
        private final String name;
        private final String path;

        @JsonCreator
        public ProjectResource(String name, String path) {
            this.name = name;
            this.path = path;
        }

        public String name() {
            return name;
        }

        public String path() {
            return path;
        }

//equals, hashCode, toString
}

The equivalent record is as follows:

@JsonSerialize
@JsonAutoDetect(fieldVisibility = JsonAutoDetect.Visibility.ANY)
@JsonIdentityInfo(generator = ObjectIdGenerators.PropertyGenerator.class, property = "name", scope = ProjectResource.class)
public record ProjectResource(String name, String path) {
    @JsonCreator
    public ProjectResource {
    }
}

The XML being deserialized is the following:

<?xml version='1.1' encoding='UTF-8'?>
<project>
   ...
  <resources>
    <resources>
      <name>beevillage.ogg</name>
      <path>resources\1594389476\beevillage.ogg</path>
    </resources>
  </resources>
  ...
</project>

Finally, I have the following mapper (building with -parameters):

var module = new JacksonXmlModule();
module.addDeserializer(Color.class, new ColorDeserializer());

var xmlMapper = new XmlMapper(module);
xmlMapper.registerModule(new ParameterNamesModule(JsonCreator.Mode.PROPERTIES));
xmlMapper.registerModule(new Jdk8Module());

var builder = xmlMapper.readValue(Files.readAllBytes(projectXml), ProjectBuilder.class);

return builder.build(projectFile, projectXml);

When I deserialize the XML to the first class it works fine, but when I do so to the second class I get the following error: Can not set final java.lang.String field com.opengg.loader.Project$ProjectResource.name to java.lang.String

Maybe I'm doing something wrong, but my understanding of the record constructor syntax is that it generates the constructor in the same format as the immutable class, including any annotations. If the two classes are identical, I don't see a reason why the deserializer would be unable to use the constructor in the record case but have it work fine in the class case.

EDIT: This seems to be related to #3297.

yihtserns commented 1 year ago

What is the purpose of @JsonIdentityInfo(generator = ObjectIdGenerators.PropertyGenerator.class, property = "name", scope = ProjectResource.class)?

cowtowncoder commented 1 year ago

That definitely seems extra without other info.

Also, that @JsonSerialize is unnecessary on class.

Maybe they were copied from some place without fully understanding semantics?

cowtowncoder commented 1 year ago

@javster101 Although ideally Records and similar POJOs would work same way, due to implementation challenges there are definitely cases where this is not true -- constraints that Records have did/do not exist for POJOs, and as such handling has been created initially for general POJOs and only later trying to make use of & support limitations Records have.

Also: 2.13.0 is old version so please try it out with 2.15.2 -- there have been many recent fixes to Record-type handling in 2.15 (as well as in 2.14).

yihtserns commented 1 year ago

BTW, I asked about the @JsonIdentityInfo because:

cowtowncoder commented 1 year ago

One other final note: there's reference to XML, so issue may well be related to XML format module. And there have been TONS of fixes there since version 2.13.