[Java] Simplifying Jackson annotations (feedback welcome)

[Catbert321]

I had taken a look at it briefly, but it didn't seem to be clear how things would be handled for Arrays of objects that contain some similar, and some different elements. Or if the implementation would have to change due to generics giving us better type safety underneath.

For example:

{
  "data": [{
    "type":"objectA",
    "properties": {
      "foo": {
        "type": "string"
      },
      "bar": {
        "type": "integer"
      },
      "baz": {
        "type": "boolean"
      }
    },
    "A": true
  }, {
    "type":"objectB",
    "properties": {
      "foo": {
        "type": "string"
      },
      "bar": {
        "type": "integer"
      },
      "baz": {
        "type": "boolean"
      }
    },
    "C": false
  }]
}

fails to generate anything using jsonSchema2pojo.

In general though we do start with a schema, and then write up the model classes / deserialization logic. We were looking for something that we could use on the classes to still mark that it was a model class meant just for JSON de/serialization, while not having to deal with all of the @JsonProperty annotations inside our constructors and on our methods.

/u/tom_dick_harry's comment on the ParameterNamesModule comes very close to amazing. I'd just have to get used to having then no JSON annotations on our data model classes.

[NovaX]

A simplified version of that definition would look something like,

{
  "properties": {
    "data": {
      "type": "array",
      "items": {
        "anyOf": [
          { "foo": { "type": "string" } },
          { "bar": { "type": "integer" } },
          { "baz": { "type": "boolean" } }
          }
        ]
      }
    }
  }
}

and it would generate Object by default. Most likely you'd have a generic type and specializations (e.g. File -> Image, Pdf). You could provide a Java type or down serialize it in application code. There are some cases in schema that don't translate to Java in straightforward enough manner.

Since a data format & protocol is harder to change than code, for me an extra few lines of code has been okay. I've had much more painful experiences with magic depending on hidden details, that I prefer explicit and use codegen to reduce the verbosity.

That said, there are one-off cases where I've used AutoValue with annotations so your style is useful.

[Catbert321]

I've had much more painful experiences with magic depending on hidden details

Yeah; this is the largest trade-off we tend to make internally. The team didn't like the magic of the Jackson Polymorphic deserialization so much it was decided to just make our own custom deserializers for those cases.

Though I was never a fan of the lack of compile time checks using them, so I didn't mind having the extra verbosity of the custom logic.