Sounds like normal life to me. Please give me $$$$
The Order of the JSON
11–20 of 126 posts
Re: The Order of the JSON
#12How were they going to charge him for 9 FTEs for 6 months to uncheck a checkbox?
Re: The Order of the JSON
#13Ha! Stephen Dolan had to add this to jq quite sometime back, making it preserve object key input order on output. And yes, it's infuriating, but it's also somewhat convenient, and yes, there really is software out there that cares about object key order (sigh).
Re: The Order of the JSON
#14How were they going to charge him for 9 FTEs for 6 months to uncheck a checkbox?
Write some software that reordered it probably.
Re: The Order of the JSON
#15This makes my head hurt. I wonder if you end up with sorting differences depending on the locale?
Re: The Order of the JSON
#16Earlier quoted context omitted.
OK. I totally prefer ordered JSON, because it is so much easier to eyeball - to visually compare JSON with different ordered keys is quite a lot more difficult (O() complexity?) than if they are in the same order. It also enables diff to help see where the differences are (diagnosis, not just binary identical or not). And, in fact, I do use ordered JSON for comparison in testing, as you describe. However ... comparis…
+1 for all reasons above for ordered JSON, highly convenient in practice. And if it doesn't impact performance significantly, these are all pretty good reasons for JSON outputters to default to sorting objects deterministically by keys, or at least to provide a flag to do so. (Even if there's no canonical sort order between JSON libraries, all that matters is it's deterministic for each library.) BUT... I can't imagi…
I guess because OrderedJSONObject is ordered, not sorted. Like java's LinkedHashSet, it maintains the order keys are added.
If you're going to rely on a specific order for comparisons, it makes sense to alert the user to any JSON in a different order (instead of silently, liberally accepting it), or you'll get false negatives elsewhere. Easier to check for a sorted order, but also possible to define a specific order. IDK what IBM did here.
funfact: jq used to sort keys; now it retains ordering.
Re: The Order of the JSON
#17Writers should produce sorted maps, readers need to accept unsorted maps.
It's a security issue, not just convenience. With unsorted maps the internal hash seed can be exposed, together with timing information.
Another famous omission from the specs.
Re: The Order of the JSON
#18I wrote a json serialization/deserialization library for C++ and if you provide the members in the order they are specified in the type you get better performance. It can construct the class without having to bounce the parser back to that location and it is much much more cache friendly.
Re: The Order of the JSON
#19Writers should produce sorted maps, readers need to accept unsorted maps. It's a security issue, not just convenience. With unsorted maps the internal hash seed can be exposed, together with timing information. Another famous omission from the specs.
I’m no security expert. How is “exposing the hash seed” a problem for the vast majority of applications? What timing information would be leaked and why would that be problem?
On the other hand, accepting unsorted maps seems like it could introduce covert channels?
Re: The Order of the JSON
#20I wrote a json serialization/deserialization library for C++ and if you provide the members in the order they are specified in the type you get better performance. It can construct the class without having to bounce the parser back to that location and it is much much more cache friendly.
I also would much rather write code that doesn't quite do what it's supposed to if it's easier to do and I can take an extra day off. However, that's not my job.