You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've got a user question in Johnzon whether setting PropertyOrderStrategy should end up sorting Map and Set fields as well.
My personal interpretation from reading the spec is that it only applies to class fields (JSON-B properties).
public class Bla {
private String b = "bla;
private Map<String, Integer> a = new HashMap<>();
...
a.put("x", 4);
a.put("y", 5;
...
}
Might end up as
{"a":{"y":5,"x":4},"b":"bla"}
Note that while the field members are sorted (a,b) the Map values are not.
Something to keep in mind that Map, Set, etc most times already have a very distinct ordering which is depending on the concrete implementation. E.g. if we have a HashMap then it is always unsorted. And even if we would call the add() operations in the 'correct' order then it will still end up random in the HashMap. Same applies to TreeMap which is always sorted after the key.
So it might only have an impact on the writer side anyway, isn't?
And there it might cause a useless performance impact in case we don't need the sorting.
Because the default ordering in JSON-B is Lexigraphical, isn't?
So that would mean that we would not be able to just write out the Map but first would need to sort the keys and then write out the values in that order. Sounds a bit too much for me in most cases.
We could probably introduce another config flag to indicate default sorting of collections?
What about order applied as annotation to a Map or Set directly?
The text was updated successfully, but these errors were encountered:
@bravehorsie Commented
For class properties sorting can be done during initialization / class scanning. Sorting collections in runtime will impact performance significantly if done by default.
Collections has their sorting contract well defined outside of JSONB, it does not sound reasonable to me to override it.
For now we are ordering just the keys in json document which relates to Map implementations, but if we declare that we override collection sorting what will we do about non-keyed ones - comparing toString result?
We've got a user question in Johnzon whether setting PropertyOrderStrategy should end up sorting Map and Set fields as well.
My personal interpretation from reading the spec is that it only applies to class fields (JSON-B properties).
Might end up as
Note that while the field members are sorted (a,b) the Map values are not.
Something to keep in mind that Map, Set, etc most times already have a very distinct ordering which is depending on the concrete implementation. E.g. if we have a HashMap then it is always unsorted. And even if we would call the add() operations in the 'correct' order then it will still end up random in the HashMap. Same applies to TreeMap which is always sorted after the key.
So it might only have an impact on the writer side anyway, isn't?
And there it might cause a useless performance impact in case we don't need the sorting.
Because the default ordering in JSON-B is Lexigraphical, isn't?
So that would mean that we would not be able to just write out the Map but first would need to sort the keys and then write out the values in that order. Sounds a bit too much for me in most cases.
We could probably introduce another config flag to indicate default sorting of collections?
What about order applied as annotation to a Map or Set directly?
The text was updated successfully, but these errors were encountered: