Support for const keyword

[ddcruver]

trafficstars

Could support for the const keyword be added? https://json-schema.org/understanding-json-schema/reference/generic.html#constant-values

• Where field and a getter method is added to the pojo but no setters or builder methods should exist for it.
• A @JsonIgnore would also be added to avoid it from being used in serialization and deserialization.

Use Case: Adding constant fields to a hierarchy of pojos where the value could be changed on each one of them.

A special case would be possibly in order to inform end-user of the schema when type information provided for polymorphic type handing should be included in JSON. https://github.com/FasterXML/jackson-docs/wiki/JacksonPolymorphicDeserialization#12-per-class-annotations. Where with a properly configured Jackson ObjectMapper a field such as "@class" would be used for deserlization.

[joelittlejohn]

I like the idea of using const to return a fixed value and having no setter. I don't think skipping this field during serialization is the correct thing to do though. JSON produced from the POJO should include the value, no?

[ddcruver]

When serializing yes in general it should write this value but in limited cases you wouldn't want it to write it because it is handled by the library anyways.

For example if you use the type info feature of Jackson you can write the class (amount other things) as a field ( commonly @class) in the JSON to aid in deserialization.

[ghost]

I agree that the baseline is to include it in serialization. Excepting from that is another feature.

[ddcruver]

Revisiting the documentation I am thinking maybe we should consider an implementation more close to the definition of the standard. JSON Schema - Generic keywords #constant-values

It should be noted that const is merely syntactic sugar for an enum with a single element, therefore the following are equivalent: { "const": "United States of America" } { "enum": [ "United States of America" ] }

Possibly we should support both interpretations:

• strict - a single value enum is created, therefore enforcing the validation that the json matches the schema, all getter/setter/builder methods should be implemented.

  • The java code may look odd with an enum with one value but will match the schema.
  • The constant value would be an enum and value() would need to be called to get the const value.
  • An example use case would be that a const could eventually become enum with the original value plus more and existing JSON would be still valid.
  • An incorrectly provided constant value in JSON will be a deserialization problem and will cause an exception in something like Jackson.

• loose - on serialization the constant value is always written but in deserialization the value is ignored. A getter exists but a setter does not.

  • The java code would look more natural, the property would be a final that could not be changed
  • The getter could return the actual type of the enumeration, String in most cases but could be anything including a double.
  • An incorrectly provided constant value in JSON will be ignored and not cause a deserialization problem. When the same object is serialized back it will contain the correct value for the constant.

In either case the JSON produced by the pojos will always have this constant value. The deserialization logic will differ but it should be made impossible to get an instance of the class where the constant value is different then what is expected.

[ddcruver]

Thinking about it more I think maybe we can cause a serialization exception on the loose interpretation but would involve a serializer be written specifically for it that ensures the value matches the expected value.

https://fasterxml.github.io/jackson-databind/javadoc/2.3.0/com/fasterxml/jackson/databind/annotation/JsonSerialize.html

I'm not sure how to do it in gson.

[danidemi]

Hi! Just to let you know that I also have the same issue. I have "const" in a schema I'd like to map to Java but it is rendered as a plain property.

[lurbain-qs]

Hi, I would also be interested in this feature. Are you planning on supporting "const" in the future?

[PhilippKemkes]

Are there any updates on this? I would be glad if const fields would be handled. Both suggested ways are fine.