property order in subclass

[ogerardin]

Say I have 2 schemas a.json and b.json that generate classes A and B.
In b.json I "inherit" a.json using the "extends" mechanism.

In the generated classes A and B there is a JsonPropertyOrder annotation that specifies the correct property order; however, when serializing, B's properties appear before A's properties in the resulting JSON.

Is there a way to make Jackson serialize the super class properties before the subclass?

[dewthefifth]

According to https://stackoverflow.com/questions/17995623/jsonpropertyorder-and-fields-from-the-super-class it looks like it should be ignoring the property order declared in A all together. If that's the case, we may need to update the property order declared in B to enforce that A properties are written before B properties.

However, as I'm not particularly savvy with the JSON schema standard, I have to ask whether super class properties preceding subclass properties is part of the standard or is it simply something you'd prefer? How do we know that it should be A->B instead of B->A?

In the short term, you can solve the problem using a jackson mixin, but that's understandably not a good solution since it requires you to make mix ins for all of your classes that have inheritance.

[ogerardin]

However, as I'm not particularly savvy with the JSON schema standard, I have to ask whether super class properties preceding subclass properties is part of the standard or is it simply something you'd prefer? How do we know that it should be A->B instead of B->A?

I think it's just a matter of preference, really, so I'm not sure this is even a bug. But I think "superclass properties before subclass" is what makes most sense.
The order of fields in a JSON object is not significant, but JSON documents are also sometimes read by humans so there should be a way to control this.

In the short term, you can solve the problem using a jackson mixin, but that's understandably not a good solution since it requires you to make mix ins for all of your classes that have inheritance.

I don't have that many so I might do this as a workaround.

[ddcruver]

I could see cases where you would want either one first. I would say most of the time though that I would prefer the super class first then the subclass. The best reason would if the base class defines a id I would like that to be first regardless of which class in the hierarchy is used.

I could see the following property order control to be defined:

• Super Class -> Child Class
• Child Class -> Super Class
• Super Class Required -> Child Class Required -> Super Class Optional -> Child Class Optional

There is lots of discussion on the json schema project about this and I am not sure if it all resolved at some point. There was talk of moving it to sub-schemas like a json schema for UI.

[ddcruver]

Brainstorming of Implementation Types:

• Single Static Property Order, non configurable
• Built-In Property Orders defined in Generation Config
• Built-In Property Orders defined in Generation Config with providing custom implementations for "ordering things" (could be made general purpose to maybe support toString or equals methods etc.)
• Defined In Schema itself
  • In-Place with Property Definitions
  • Separate extension property, similar to javaEnums/javaEnumNames
• .... more?

[ogerardin]

There is lots of discussion on the json schema project about this and I am not sure if it all resolved at some point. There was talk of moving it to sub-schemas like a json schema for UI.

Do you have a link to this maybe ? I'm surprised this is a concern of the json schema project, as a schema is mainly a definition of validity and we know that in this respect, the order of properties is not relevant.

[ddcruver]

json-schema-org/json-schema-spec#571
json-schema-org/json-schema-vocabularies#7

[ogerardin]

Some progress about this:

I was set to write a custom annotator to include the parent class properties first in the PropertyOrder annotation, but then I did an experiment: I removed the PropertyOrder annotation altogether in one of the generated subclasses, and what happened was that the properties were serialized in the expected order: parent class properties, then subclass properties (in class order)!
So, my conclusion is that Jackson's serialization strategy is:

1. first, all properties specified in PropertyOrder
2. then all remaining properties from parent class (recursively)
3. then all remaining properties from subclass (in class order)

By generating a PropertyOrder, we actually tell Jackson to serialize the subclass properties first.

My workaround for this is to use a custom annotator that extends Jackson2Annotator, and replaces the propertyOrder method with a no-op:

public class CustomAnnotator extends Jackson2Annotator {
    public CustomAnnotator(GenerationConfig generationConfig) {
        super(generationConfig);
    }
    @Override
    public void propertyOrder(JDefinedClass clazz, JsonNode propertiesNode) {
    }
}

By systematically using the PropertyOrder annotation, we force Jackson into a behavior which is not "natural". Without the PropertyOrder annotation, Jackson does the least surprising thing. My suggestion would be to make this the default behavior

[solsson]

Without the PropertyOrder annotation, Jackson does the least surprising thing

IMO it's great that the generated @JsonPropertyOrder preserves the order of the properties in the schema (I've tested with sourceType=yamlschema). That allows an ordering that is relevant to the doman.

[ogerardin]

Without the PropertyOrder annotation, Jackson does the least surprising thing

IMO it's great that the generated @JsonPropertyOrder preserves the order of the properties in the schema (I've tested with sourceType=yamlschema). That allows an ordering that is relevant to the doman.

Of course, but if you read all the discussion form the start, you'll see that it's about the order of properties when inheritance is involved.