Hi Mark,
2016-12-04 23:32 GMT+01:00 Mark Struberg <struberg_at_yahoo.de>:
> Hi folks!
>
> I would like to give a bit feedback on using JSON-B in a real-world app.
>
> All works fine in JSON-B _if_ there are getters and setters.
>
> But it seems that JSON-B by spec ignores private fields if you don't have
> get/set for it (3.7.1) :(
> Here is my use case:
> ----
> public class SomeAttributeMap implements Serializable {
> private Map<String, DocAttribute> attributes = new HashMap();
>
> public DocAttributeMap putAttribute(String name, Object value) {
> attributes.put(name, new MyAttribute(value));
> return this;
> }
>
> public Object get(String name) {
> DocAttribute att = attributes.get(name);
> return att != null ? att.get() : null;
> }
> }
> ----
>
> The point is that 'attributes' is a private field. It is INTENTIONALLY
> private. I do not like to expose the internal details to the user!
>
> Creating a new SomeAttributeMap and put("x", 123); should result in the
> following JSON:{attributes=[{"x":1234}]}
> But what I get is {}...
>
> I also already tried @JsonbProperty, without success.
>
> And implementing an own PropertyVisibilityStrategy is possible but
> seriously overkill.
> I'd probably go that route IF there would be a default one for all_fields
> provided inside the JSON-B spec.
>
> Of course i can make it work, but what about the other 500k developers
> which are not that deep into it?
> Currently it is not as easily useable as JSON-B should be imo.
>
> a.) Why does adding a @JsonbProperty not have any impact? Is this a bug we
> missed in Johnzon or really spec defined?
> I mean, if someone *explicitly* annotates a field, why do we ignore it?
> From reading the spec it doesn't seem clear to me whether the paragraphs
> 4.1.2 javax.json.bind.annotation.JsonbProperty and
> 3.7.1 Scope and Field access strategy have a higher priority.
> Can anyone clarif this please?
>
>
Yes, there is a "introspection area" which ignores any @JsonbX not in that
area. That said I agree for these simple cases we could still check for the
"current" class if @JsonbX is used and then respect it.
> b.) Should I open a ticket for the default VisibilityStrategies for
> all_fields?
>
>
+1 for a MR
> A few other catches:
> c.)
> > Any instance passed to a deserialization operation must have a public or
> protected no-argument constructor.
> Shouldn't that just be: "... must have a no-argument constructor." ?
> Why does it need to be public or protected? Technically this restriction
> doesn't appear to make much sense.
> JSON-B does not do any subclassing, so i could even be a private default
> ct.
> If you say you need subclassing then probably '.. must have a non-private
> no-arg constructor.'
> Can someone please shed a light on this decision?
>
>
Think it is not a big constraint today and we can surely relax it.
> txs and LieGrue,
> strub
>
> PS: Dmitry, sorry to disturb you. Just adding you as I'm not sure who
> moderates this list.
>
>
>