FasterXML
Feature Request: Add full deserialization support to @JsonPropertyOrder annotation
Hello. This cannot be classified as a defect because annotation doc clearly says: "This annotation may or may not have effect on deserialization"
Ordering during serialization may be enough if other side (web app UI for instance) does not change the order of fields on their side. But for JS UI frameworks it is rather common to serialize JSON fields in alphabetical order. (Angular HTTPClient is a good example).
As the result - field order in JSON is changed and for whatever reason @JsonPropertyOrder was added to an Entity - it doesn't help anymore.
There's a bunch of way to solve it (field renaming, custom Deserializer, getting rid of dependency on fields order to name the few), but having a natively supported annotation is the best.
Just to make sure I understand: you are requesting that order in which properties are set (via field or setter method) would be forced with a setting, to be made in order @JsonPropertyOrder specifies?
I can understand that part, but not necessarily the benefit: how would processing be affected by order?
This setting affects POJOs, mostly, but I guess it may also affect Maps.
Can you give a brief outline of processing where this would be useful, to retain ordering?
Here's an example you have an object with 3 attributes:
- name
- type
- properties
HttpClient sends Json alphabetically - name, properties,type
If I annotate a class @JsonPropertyOrder("name", "type", "properties) I would like attributes to be deserialized in that exact order, not alphabetical.
This is beneficial for the cases when for example properties are deserialized depending on value of type. I know that JSON spec says that order should not matter, but unfortunately there are cases when this is unavoidable (my case - large legacy project UI redesign with backend refactoring strictly forbidden).
@el-denis Ok. Thank you for explaining this. I can see how this could be beneficial.
It might be most sense to require setting to enable this behavior because it does add overhead for sorting, and very likely buffering of all the content, to ensure in-order processing. And with buffering, potential loss of location information.
So since ordering is often not needed, it probably makes sense to require opt-in for additional processing. This could be a property for @JsonProperty annotation.
One work-around that may be helpful is using a "creator" (constructor or static factory method in class itself), annotated with @JsonCoreator, instead of setters. Benefit is that creator is only called after all properties to be passed are deserialized. However, this does NOT need to be all properties.
You could, for example, only require type to be passed via creator, and then handle "properties" via setter -- that would be guaranteed to be called only after "type" has been passed via Creator.
@volkert-fastned I am not aware of anyone working on this. Usually updates are indicated by writing a comment on issue. I do not plan working on this myself, but if anyone wants to work on it I can help with a PR.
We don't assign issues in Jackson. You can work on it. Make sure to read contributing guide tho.
Yes, @krish2kdev if you want, you can try.
I personally still do not see much point to this, especially considering likely added complexity, overhead. And I am skeptical of the result being worth it.
But if you do think it is important, doable, go for it. :)