Moshi: @Json annotation to override the field name

[swankjesse]

An example:

class Customer {
  @Json("full name")
  String fullName;
}

(We _won't_ support general policy-based name mangling, like converting camelCase to snake_case or kabob-case)

[inder123]

How about making this equivalent to Gson @JsonAdapter annotation?
The developer should be able to specify arbitrary type adapter for a field and class.

[swankjesse]

Moshi looks up type adapters by type + annotation. So you can do @UnixEpoch long authenticatedAt and register the corresponding adapter in Moshi. I'm slightly reluctant to support @JsonAdapter, but I can be convinced!

[inder123]

The biggest benefit of JsonAdapter (from my perspective) is that it allows me to specify the custom type adapter for my class without requiring the Gson instance to register it.

In Moshi, how do you propose to automatically register a custom type adapter for a type?

[swankjesse]

The closest we'll come to automatic JSON binding is this: https://github.com/square/moshi/issues/29

[inder123]

that works, and also takes care of subclasses

[JakeWharton]

@JsonName? Not that I don't like @Json or anything.

[swankjesse]

Would it be dual-purpose? @Json(value="foo", adapter=FooJsonAdapter.class) ?

[meoyawn]

can you please explain why you don't want a general field name policy support?
since most of the json is generated from python/ruby field naming conventions, and the policy itself is just a String -> String function

does this have to do to the efficient okio-based nature of moshi? (but then again @Json will be supported somehow)

[swankjesse]

We don't support field naming policy because it breaks grep. Programming becomes a lot easier once you commit to not breaking grep.

(If you see a field like shipping_address in your JSON, you can search for that in your code and find it.)

[mehdibaha]

Hi,
I'm sorry but I need to ask this question (since it's the only reason why I haven't adopted moshi yet) :
Who need to grep his code for a particular field name only found (normally) in the server code.

When you arrive at the client code, all the field naming conventions change, and you can start grepping for ShippingAdress, so I don't see how that's a reason for you not implementing yet policy-based name mangling.

[swankjesse]

@mehdibaha strictly following Java's conventions is unnecessary. You make the whole thing simpler by just using the same names on client and server.

[mehdibaha]

You're usually following Java's conventions in other areas of your code, so for an other reader (or yourself after a few months not looking at the code), it's extremely confusing to see two conventions used inside one codebase. Hence the unique convention.

[mdesoto]

I have to agree with @mehdibaha here. I'll add that forcing a 1:1 naming relationship might work great when you're controlling both the API and the Client. However, my company routinely integrates with multiple third parities in the same project. It seems like a silly constraint to be forced to use whatever arbitrary naming policy the third party is using. And two different conventions can turn to 10 very quickly.

And @swankjesse: Strictly following Java's conventions may be unnecessary in your circumstance, but in mine, my engineering department uses a well defined set of coding standards. And the argument that we'd have to change them in some circumstances because our favorite resource for quality libraries (that's you guys) says it's unnecessary isn't going to cut it.

Sure, one could argue that there are myriad libraries for JSON serialization/deserialization, and that we should go with one of those. Sure. But there's a reason we look to you guys. And that's the same reason others will keep piping in to request this feature. Just a prediction.

[swankjesse]

https://github.com/square/moshi/pull/68

[mehdibaha]

I think you've made the right choice. Thanks.