Range property name (de)serialisation doesn't respect property naming strategy

[philleonard]

Field names in the Guava Range<T> are serialised and deserialised with the hard coded values lowerEndpoint, lowerBoundType, upperEndpoint and upperBoundType:

    {
      "lowerEndpoint": 1,
      "lowerBoundType": "OPEN",
      "upperEndpoint": 10,
      "upperBoundType": "CLOSED"
    }

For consistent JSON field naming it would be nice to support other property naming strategies. For example snake case:

    {
      "lower_endpoint": 1,
      "lower_bound_type": "OPEN",
      "upper_endpoint": 10,
      "upper_bound_type": "CLOSED"
    }

Please see here for the basic idea philleonard@8a3f36f. Happy to open this as a PR and change to whatever is the correct way of formatting field names when writing them as strings.

[cowtowncoder]

True, since there's custom (de)serializer, instead of default POJO one, field names are essentially hard-coded. Would be happy to work on improvement.

On proof-of-concept, calling field name mutators on-the-fly is bit cost-prohibitive, so I would not want that to occur at time of (de)serialization. But you should be able to do that instead in createContextual() (implement ContextualSerializer / ContextualDeserializer), and then re-create new (de)serializer if naming convention exists. That is the canonical way of applying such changes anyway.

Actually, come to think of this, there may be even simpler way to achieve early changing. (De)Serializers are registered by GuavaModule, via GuavaDeserializers and GuavaSerializers.
Methods (findXxXDeserializer() / findSerializer()) are passed BeanDescription (as well as config), and that should have access to naming convention configuration as well.

Let me know if you need more information on above: I don't think I have done this for other custom/external (de)serializers but there should be no blockers.

[philleonard]

Hi @cowtowncoder, thanks for your quick response. BeanDescription (cast to a BasicBeanDescription) only has the protected field access to the MapperConfig where we can gain reference to the PropertyNamingStrategy. So I don't see any way to do this without reflection or a change to jackson-databind unless I am missing something?

I have gone ahead with your first suggestion for the time being #57. Let me know what you think.

[cowtowncoder]

Access to MapperConfig is most commonly via sub-class (DeserializationConfig, SerializationConfig both extend it) references: either directly passed to

       public JsonDeserializer<?> findBeanDeserializer(JavaType type,
            DeserializationConfig config, BeanDescription beanDesc)
                throws JsonMappingException

or accessible via context (SerializerProvider / DeserializationContext have getConfig() or something).

So that is how you can access globally configured strategy via getPropertyNamingStrategy().

However, ideally there probably should be a mechanism to allow per-class overrides (in fact, theoretically it should be possibly to apply mix-in to Range....). I think I'll file a separate issue for considering of how that should be exposed.

But for now I think use of global default would make most sense.