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?
b.) Should I open a ticket for the default VisibilityStrategies for all_fields?
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?
txs and LieGrue,
strub
PS: Dmitry, sorry to disturb you. Just adding you as I'm not sure who moderates this list.