(note: same/similar as #1709 )
Hi,
After discussing this matter on the mailing list, IÂ was redirected to creating an issue to ease some use case of @JsonUnwrapped.
Basically, my objective is to avoid using mutable objects and exploit as much as possible constructors to construct objects.
Taking this example:
class Location {
public final int latitude, longitude;
public Location(int latitude, int longitude) { ... }
}
class Place {
public final String name;
@JsonUnwrapped public final Location location;
@JsonCreator
public Place(@JsonProperty("name") String name,
@JsonProperty("latitude") int latitude,
@JsonProperty("longitude") int longitude) {
this.name = name;
this.location = new Location(latitude, longitude);
}
}Currently, deserializing a Place object fails because Jackson first builds the Place object (successfully, including the location with the correct values) and then tries to set the location field. The latter fails because the latitude and longitude properties were already used to construct the Place, and thus are not used to construct the Location.
At the end of the deserialization process, the location field is initialised with an object with null values for latitude and longitude!
I would expect Jackson not to try to set the location field after a Place object was successfully constructed since a constructor is expected to build fully constructed objects?
Apparently (according to the discussion on the mailing list), the following code should have worked:
class Location {
public final int latitude, longitude;
public Location(int latitude, int longitude) { ... }
}
class Place {
public final String name;
@JsonUnwrapped public final Location location;
@JsonCreator
public Place(@JsonProperty("name") String name) {
this.name = name;
this.location = null;
}
}I.e., the Place object is partially created, and then Jackson would set the location field.
In practice it didn't work, not sure why. But with respect to my proposed solution to the first problem of this issue, I'm not sure it is a so good idea that this second way of doing things work: for me a constructor is meant to fully build an object!
FYI, the only solution I found to work is to have a parameter-less constructor and let Jackson handle everything its way. IÂ feel there is some use case where a constructor would really be needed, for example if the properties must be reworked a bit before being set to the object (keeping in mind I don't want to use setters :).
(note: same/similar as #1709 )
Hi,
After discussing this matter on the mailing list, IÂ was redirected to creating an issue to ease some use case of
@JsonUnwrapped.Basically, my objective is to avoid using mutable objects and exploit as much as possible constructors to construct objects.
Taking this example:
Currently, deserializing a
Placeobject fails because Jackson first builds thePlaceobject (successfully, including thelocationwith the correct values) and then tries to set thelocationfield. The latter fails because thelatitudeandlongitudeproperties were already used to construct thePlace, and thus are not used to construct theLocation.At the end of the deserialization process, the
locationfield is initialised with an object withnullvalues forlatitudeandlongitude!I would expect Jackson not to try to set the
locationfield after aPlaceobject was successfully constructed since a constructor is expected to build fully constructed objects?Apparently (according to the discussion on the mailing list), the following code should have worked:
I.e., the
Placeobject is partially created, and then Jackson would set thelocationfield.In practice it didn't work, not sure why. But with respect to my proposed solution to the first problem of this issue, I'm not sure it is a so good idea that this second way of doing things work: for me a constructor is meant to fully build an object!
FYI, the only solution I found to work is to have a parameter-less constructor and let Jackson handle everything its way. IÂ feel there is some use case where a constructor would really be needed, for example if the properties must be reworked a bit before being set to the object (keeping in mind I don't want to use setters :).