Open misl opened 5 years ago
I like the idea of supporting the builder pattern in JSON-B, since it's a common alternative to a public all-args constructor when creating immutable objects.
I'm -1 to get it as a core feature since it quits the scope of JSON-B because it is basically defining another way to map an object on top of JSON-P (so a sibling and not a child of the spec) but it can be an appendix of the spec (i.e. an optional part/proposal).
Without support for Builder Pattern JSON-B is, in my opinion, practically useless for many developers.
It is not really important to me how this can be done as long as it it possible to use the Builder Pattern. An option might be to allow using the @JsonbCreator on the Builder class and refer to the class being created. Or maybe at class level of the original class and have it refer to the builder class and build method.
@misl did you give a try to adapters to implement the builder pattern? it works not bad and avoids to create a concurrent model. Also I kind of disagree on the useless side, jsonbcreator enables immutable objects quite well and mainstream style is still anemic POJO for JSON mapping so don't hide this part of the iceberg under the the builder pattern which is actually the exception today IMHO.
@rmannibucau primary reason why I haven't switched to JSON-B yet is my requirement for immutable objects. Initially I thought I could use @JsonbCreator, but it appears in that case all arguments are mandatory. Which also conflicted with my requirements. There is some discussion on this subject in https://github.com/eclipse-ee4j/yasson/issues/237 . I tried to get around this. Even sent in a PR, but it was rejected as current reference implementation is in line with the standard. So my experience is that for immutable objects @JsonbCreator might only work well in edge cases.
But even then, if for a constructor or creator method the number of arguments exceeds some arbitrary limit (say 5 or 10) the code becomes smelly and maintenance unfriendly.
I agree it could be solved with an adapter. JsonbCreator can also be solved with an adapter. Yet there is a separate annotation for that. Also it requires me to write an additional class. In comparison with Jackson, I only needed 2 annotations. My mantra mostly is: more code leads to more maintenance. So when I can do with less code I prefer it.
Is JSON-B only intended for a mainstream coding style?
@misl I will likely repeat a few things spread accross tickets so don't take it badly if obvious but here is my view on that kind of issue:
So long story short I would propose to push to get 1 ASAP instead of trying to get something probably half baked.
Hope it makes sense.
It's a nice feature, but I disagree that it's must have feature. Deserialization of immutable objects can be achieved by using @JsonbCreator
or by annotating class properties with @JsonbProperty
or (in future) by using runtime configuration. Possibly we should think how to make runtime configuration API builders friendly.
@m0mus if we get an introspector API (reflection abstraction) as mentionned in a few other tickets then we can let it be set on the JsonbConfig. This enables to handle fluent API (not builder but here the builder = fluent API + factory method) then it is just a matter of adding a deserializer which uses the builder instead of the main class and calls it (it is a one liner).
Currently using JSON-B with immutable objects is hardly doable.
@JsonbCreator is only partially helpful here, but makes all parameters required. But also with many parameters the solution starts to smell. Normally one would use the builder pattern in this scenario. However unlike Jackson (@JsonPOJOBuilder) JSON-B does not support it.