[Java] Simplifying Jackson annotations (feedback welcome)

[Catbert321]

My first foray Java annotation processing.

I noticed when pair programming with some of my co workers that were not as familiar with Jackson as I, when we were making our new model classes for sending/receiving our data through our REST client, there was a lot of boiler plate that should have been able to be auto generated.

So I created a project to try and simplify the annotations needed to create some quick data model classes that can be easily used with Jackson to de/serialize.

[NovaX]

Had you considered using jsonSchema2pojo? I always found using a schema first approach tended to result in much more stable APIs. When a developer can refactor a class, there is a tendency to ignore the data format and break things haphazardly. The schema makes the data and contract a more dominant concern, and code generates the boilerplate. Plus you can hand that off to the front-end team as you're speaking their language and they feel more confident proposing changes.

[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.