On Thu, May 3, 2018 at 4:20 AM, Burak Emre Kabakcı <[email protected]> wrote: > I have the following class: > > class SimpleFilterItem(@JsonProperty("type") type: String, > @JsonTypeInfo(use = JsonTypeInfo.Id.NAME, property = > "type", include = JsonTypeInfo.As.EXTERNAL_PROPERTY) > @JsonSubTypes(value = [ > JsonSubTypes.Type(value = StringOperator::class, > name = "STRING"), > JsonSubTypes.Type(value = NumericOperator::class, > name = "LONG"), > JsonSubTypes.Type(value = NumericOperator::class, > name = "DECIMAL"), > JsonSubTypes.Type(value = NumericOperator::class, > name = "INTEGER"), > JsonSubTypes.Type(value = NumericOperator::class, > name = "DOUBLE"), > JsonSubTypes.Type(value = DateOperator::class, > name = "DATE"), > JsonSubTypes.Type(value = BooleanOperator::class, > name = "BOOLEAN") > ]) > val operator: Operator) > > > > However JsonSubTypes doesn't seem to support case-insensitive values so the > value `string` fails. I also have the following enum: > > enum class FieldType(val operatorClass : Class<*>) { > STRING(StringOperator::class), INTEGER(NumericOperator::class), > DECIMAL(NumericOperator::class), DOUBLE(NumericOperator::class), > LONG(NumericOperator::class) > > } > > > What I want to do to is to map the FieldType with the values instead of > writing the STRING, LONG etc. by hand. I can also implement @JsonCreator to > FieldType and solve the case insensitivity problem there. The main benefit > of this approach is that I won't be duplicating the code.
At this point you would probably need to implement custom `TypeIdResolver`, which may be registered using `@JsonTypeIdResolver` annotation. In theory we could add a feature to either use default/type-specific case-insensitivity flag to apply to type ids too (if this can be determined from base type); or, if not, additional property for `@JsonTypeInfo` to indicate that ids are to be handled in case insensitive manner. This can not be made default for couple of reasons; there are performance implications, but more importantly some users really dislike idea of coercing values -- there are endless disagreements it seems between developers who want things to "just work" (do whatever you can to mangle things to click) and those who want to ensure that strictest validation of exact matches should always be done (never accept anything even slightly askew). Either way, support case-insensitive type ids is unlikely to be added any time soon: it could go in 3.0 if commonly requested, but that'll take time (end of 2018 or later). As to enum types: this does not and can not with Java (or JVM) annotations since although specific Enum type may be used as annotation property value, there is no way to specify something like "value of any Enum type". So name unfortunately must be `String` and there is no way around that. -+ Tatu +- -- You received this message because you are subscribed to the Google Groups "jackson-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
