jackson-annotations
jackson-annotations copied to clipboard
more generic annotations
this is probably more of a consideration for 3, but could be implemented for 2 as well. I'm using the
com.fasterxml.jackson.dataformat:jackson-dataformat-yaml
but honestly this could apply to any format that's not json, it seems really odd to use @Json* annotations. I'd think that these could all just be changed to exclude the @Json so, e.g @JsonCreator would become @Creator. It might be worth making like spring and making these annotations composable, so @JsonCreator would then just "extend" @Creator for backwards compatibility.
@xenoterracide Can I work on this issue.
I don't know, I just suggested it.
@pavankrishnadev I probably should have said go for it, but I don't know that any maintainers will accept it :'(
While I 100% agree that it'd be good if we did not have Json in annotations, I just do not see a good way to address this: definitely not with 2.x -- but I am not even sure there is enough value in 3.0.
The issue is that I do want to offer one specific type of backwards-compatibility with 3.0: making jackson-annotations 3.0 be 100% backwards compatible with 2.x annotations. This means keeping same package (Maven, Java) and module ids, as well as obviously type names.
While it would be possible to offer secondary set (similar to AnnotationIntrospectorPair), that adds overhead and complexity.
And the reason for backwards compatibility itself is to avoid the major pain point of Jackson 1.x -> 2.x migration where change in annotations was a big effort to upgrade, in cases where uses cannot simply change everything. This particularly affects transient dependencies: in most cases it is simply not possible to change everything across Jackson major versions.