Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@JsonPropertyOrder(alphabetic=true) is ignored in case indices are defined for @JsonProperty #3064

Open
cdadac opened this issue Feb 21, 2021 · 1 comment

Comments

@cdadac
Copy link

cdadac commented Feb 21, 2021

After upgrading from 2.10.4 to 2.12.1 I noticed that the serialization property order has changed when serializing POJOs to JSON which are annotated with JsonProperty including an index.

This is a new feature that was added with

#2555

and is definitely a very welcome addition.

However, in case a JsonPropertyOrder(alphabetic=true) annotation is present on type level I would expect that the properties are still ordered alphabetically even though Properties with indices defined are present.

The reason is that we do not only serialize our objects to JSON but to Protobuf as well, which forces us to define indices on properties as this is required by the Protobuf serializer.

The way this feature is implemented now makes it impossible (unless there is a workaround) to support serialization to JSON and Protobuf while using alphabetic ordering for JSON format.

Since JsonPropertyOrder is defined on a type level and explicit ordering using property names still has precedence over property indices I'm wondering why this is not the case for alphabetic ordering - when I use this annotation I clearly state my intention just as if I would explicitly define the property order by name.

On the other hand, if the JsonPropertyOrder annotation is absent, using the defined indices as default order makes a lot of sense, because otherwise the order would not be clearly defined at all.

However, to improve compatibility it might even be better to add an additional property (e.g. JsonPropertyOrder(index=true)) - in this way an absent annotation would default to the legacy behavior (no well defined order) and if the annotation is present, the intended order is always explicitly defined, making it possible to extend the ordering strategy with additional options in the future.

@cdadac cdadac added the to-evaluate Issue that has been received but not yet evaluated label Feb 21, 2021
@cdadac cdadac changed the title @JsonPropertyOrder(alphabetic=true) is ignored in case an indices are defined for @JsonProperty @JsonPropertyOrder(alphabetic=true) is ignored in case indices are defined for @JsonProperty Feb 21, 2021
@cowtowncoder
Copy link
Member

This seems like a tricky problem; partly since alphabetic value uses native boolean instead of OptBoolean -- problem specifically being that there is no way to indicate "use default" (do not override). Additionally "use alphabetic ordering" is conceptually seen as a lower-precedence default compared to explicit ordering by index, so behavior is intentional.
On plus side, actual logic is (I think) relatively contained in just one location (POJOPropertiesCollector or thereabouts).

It might be that addition of a property for @JsonPropertyOrder (and perhaps global MapperFeature as well) could work in some form. That would have to go in 2.13 as we cannot make API changes in patch releases (but then again any changes to help here would need to).
And come to think of it, adding a MapperFeature would likely much easier change as it would not require all the plumbing from annotation change through to introspectors to ordering logic.
It would not allow case-by-case changes, but it sounds like in your case you would have separate mappers anyway (different backend format).

In the meantime, if a workaround is needed, it would be possible to sub-class JacksonAnnotationIntrospector to prevent use of index in cases where it is not wanted.

@cowtowncoder cowtowncoder added 2.13 and removed to-evaluate Issue that has been received but not yet evaluated labels Feb 24, 2021
@cowtowncoder cowtowncoder added 2.14 and removed 2.13 labels Jul 15, 2021
@cowtowncoder cowtowncoder removed the 2.14 label Mar 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants