Serialize bean fields in class inheritance order

[knoan]

Problem solved by the feature

Consider the following skeleton resource model to be exposed through a REST/JSON API:

public abstract static class BaseResource {
    public String id;
}

public static final class SpecificResource extends BaseResource {
    public String data;
}

With respect to output readability, especially when models grow large, it would be very convenient to have fields serialized in definition order, as:

{
      "id": "/resources/specific/123",
      "data": "resource payload"
}

However, Gson currently serializes them backward, as:

{
      "data": "resource payload",
      "id": "/resources/specific/123"
}

Quick test with:

public static void main(final String... args) {

    final SpecificResource resource=new SpecificResource();

    resource.id="/resources/specific/123";
    resource.data="resource payload";

    System.out.println(new GsonBuilder()
            .setPrettyPrinting()
            .create()
            .toJson(resource)
    );

}

Feature description

Reverse class scanning order in:

gson/gson/src/main/java/com/google/gson/internal/bind/ReflectiveTypeAdapterFactory.java

Line 228 in 6c27553

private Map<String, BoundField> getBoundFields(Gson context, TypeToken<?> type, Class<?> raw,

The current code scans classes upwards, accumulating fields in a ordered LinkedHashMap along the lines of:

private Map<String, ReflectiveTypeAdapterFactory.BoundField> getBoundFields(
  Gson context, 
  TypeToken<?> type, Class<?> raw, 
  boolean blockInaccessible, boolean isRecord
) {

    Map<String, ReflectiveTypeAdapterFactory.BoundField> result = new LinkedHashMap<>();
    
    while (raw != Object.class) {

        // …

        result.put(name, boundField);

        // …

        type = TypeToken.get(
          $Gson$Types.resolve(type.getType(), raw, raw.getGenericSuperclass()));
        raw = type.getRawType();

    }

    return result;

}

Downward class scanning could be easily performed with the assistance of a recursive accumulator method, like for instance:

private Map<String, ReflectiveTypeAdapterFactory.BoundField> getBoundFields(
        Gson context, 
        TypeToken<?> type, Class<?> raw, 
        boolean blockInaccessible, boolean isRecord
) {
    
    return getBoundFields(context, type, raw, blockInaccessible, isRecord, new LinkedHashMap<>());

}


private Map<String, ReflectiveTypeAdapterFactory.BoundField> getBoundFields(
        Gson context,
        TypeToken<?> type, Class<?> raw,
        boolean blockInaccessible, boolean isRecord,
        Map<String, ReflectiveTypeAdapterFactory.BoundField> result // ‹‹‹‹ accumulator
) {
    
    if (raw != Object.class) {
        
        // scan superclass

        TypeToken<?> superType = TypeToken.get($Gson$Types.resolve(type.getType(), raw, raw.getGenericSuperclass()));
        Class<?> superRaw = superType.getRawType();

        getBoundFields(context, superType, superRaw, blockInaccessible, isRecord, result);

        
        // scan current class
        
        // …

        result.put(name, boundField);

        // …

    }

    return result;

}

[eamonnmcmanus]

I think it might be problematic to make this change unconditionally. For better or worse, there are probably lots of tests out there that implicitly depend on the current ordering, for example comparing the output from Gson against an expected string. Those tests are already somewhat fragile, since the order in which fields are returned by Class.getDeclaredFields() is unspecified, but this change could break them further.

I'm also not convinced that it would be worth making some non-default way of configuring ReflectiveTypeAdapterFactory so it does this. And ReflectiveTypeAdapterFactory doesn't expose enough of its internals to make it straightforward to delegate to it and then change the order.

I'm open to ideas here but I think the default position is that we're probably not going to do this.

[Marcono1234]

@eamonnmcmanus, what about a general "field order strategy" which is a Comparator<(serializedName, Field)>? I have implemented a proof of concept for that in https://github.com/Marcono1234/gson/tree/marcono1234/field-order-strategy

It would allow the user to write their own order implementation, for example:

• Sort alphabetically (in POC as FieldOrderStrategy.STRING_COMPARE)
• Sort superclass first, then alphabetically (in POC as FieldOrderStrategy.SUPER_THEN_STRING_COMPARE)
  This might be similar to what @knoan is looking for. Though I am not sure if that would be needed often enough to justify providing it out of the box (users could still write it themselves though).
• Sort based on annotations (in POC as FieldOrderStrategyTest.testCustom())

This might also address #617 and #1880.

The order should only have an effect on serialization, but not affect deserialization. The default order would not be affected. Maybe this implementation does not provide the best performance for custom ordering, but when users cache their Gson instance that might not be a big problem.

What do you think about this (also about the name of this)? Though maybe I am overlooking some corner cases where this could cause issues, or maybe it would make implementing other features in the future more difficult (for example support for serializing values from getter methods; edit: could work around this be encapsulating field and in the future method in a SerializedProperty class or similar which provides methods to get declaring class, annotations, ...).

A current workaround for some of these use cases would be to serialize first to a JsonObject, then put all of its entries into a new TreeMap with custom Comparator and then serialize that to JSON.

[eamonnmcmanus]

Well, even though we've had a fair amount of activity recently, we're still technically in maintenance mode. While that doesn't mean we can't make API changes, in my opinion they would have to be clear improvements: very useful functionality that outweighs the increase in complexity. I'm not convinced that this proposed change meets that bar. I think if you're requiring your JSON fields to be in a particular order then you are probably not going about things the right way.