Support for deseralization with no type information.

[JakeAngell]

Jackson will default to using LinkedHashMap to represent JSON where there is no type information given, or the type information is given as Object.class.

Is there any support for this type of behaviour with dsl-json?

I am looking to deserialize json where a field may have varying types. For example, in my model class I have an instance variable declared as Map<String, Object> fieldName. The object value may be represented in the JSON as a string, int, object or array etc. Does dsl-json support a method of generically deserializing this into some sort of structure so it can be accessed from the instance variable.

Here is an example of some JSON that I hope to deserialize into a Map<String, Object>

 "fieldName": {
            "alwaysString": {
                "fieldInsideObject": 5
            },
            "anotherString": 40
        }

Thanks

[zapov]

Yes, you can use converter in property annotation.

[JakeAngell]

Will the databinding have to be done manually? The json structure may be different every time.

[zapov]

Not sure what you mean by manually.
You will have to set up your own converter. You can reuse existing methods from library.
For example:

@JsonAttribute(converter=MyConverter.class)
public Object property;

class MyConverter {
  public static final JsonReader.ReadObject<Object> JSON_READER = new JsonReader.ReadObject<Object>() {
    public Object read(JsonReader reader) throws IOException {
      return DslJson.deserializeObject(reader);
    }
  };
  public static final JsonWriter.WriteObject<Object> JSON_WRITER = null;
}

You can find working example at: https://github.com/ngs-doo/dsl-json/blob/master/examples/Maven/src/main/java/com/dslplatform/maven/Example.java#L33

[JakeAngell]

Okay great I think that's what I'm looking for. However, in the case of your SupportArrayList example you call a method deserializeIntNullableCollection. As far as I know there is no equivalent for a Map on the NumberConverter class?

[zapov]

https://github.com/ngs-doo/dsl-json/blob/master/library/src/main/java/com/dslplatform/json/DslJson.java#L477

[JakeAngell]

Ah it's in the DslJson class, perfect. Thanks again.

[zapov]

np :)

[JakeAngell]

Okay so using the following custom conversion class works fine apart from some unusual type resolving.

public class ExtConverter {
    public static final JsonReader.ReadObject<Map<String, Object>> JSON_READER = new JsonReader.ReadObject<Map<String, Object>>() {
        @Override
        public Map<String, Object> read(JsonReader jsonReader) throws IOException {
            return DslJson.deserializeMap(jsonReader);
        }
    };

This converter, when deserializing the following JSON will resolve the field skippable into a Long, and the player_type field into a Big Decimal.

 "ext": {
                "skippable": 2,
                "player_type": 2
            }

However, adding a trailing space to skippable's field value (as below) causes it to resolve into a BigDecimal along with player_type.

 "ext": {
                "skippable": 2 ,
                "player_type": 2
            }

Is this expected behaviour? Is there any way to change how the types are resolved? Ideally the above JSON should resolve into ints.

Thanks,
Jake

[zapov]

Yes, this is the expected behavior.
Fast path is not chosen because there is trailing whitespace after the number.

The issue is that in: https://github.com/ngs-doo/dsl-json/blob/master/library/src/main/java/com/dslplatform/json/NumberConverter.java#L1055
stops at the , instead of whitespace.
This causes it to go into slow path.

It's only an issue for this generic JSON parsing (when there are no types).

[zapov]

If you wish to change how types are resolved... you'll have to write/copy paste your own number and map converters :(

[zapov]

Hm... thinking about it some more... it's true that this could be improved...

I'll look into it when I find some free time.

[JakeAngell]

Thanks, will code around the problem for now. Aside from that great work on the library

[zapov]

I've released 1.2.1 with fixes for this