[moby_click]

If you require serialized JSON in a specific order, you are not requiring JSON, but some dialect of JSON and that should be clearly communicated. If, for some reason, a client needed a special serialization, i'd ask them for a spec, because the JSON spec does not apply anymore, and be done with it.

[jwilliams]

I think my argument is a bit different -- sure, this is an interface (maybe to a COBOL copybook in this case?). And yes, it's not "JSON".

Agree it's a leaky abstraction. Equally agree it should be documented. Often legacy systems have weirdness after seeing decades of edge-cases. Weirdness that makes them robust in all sorts of unlikely ways. Equally makes them poorly documented, leaky, opaque, and frustrating.

But I certainly have a lot of pause with the sentiment of "some idiot checked the JSON order checkbox on DataPower". My first thought is instead "I wonder why someone thought this was necessary."

[moby_click]

Yes, that sentiment is highly unprofessional. 9x6 months translates to "that box is checked for reason" and "it's not going to change". Even if things are going to change, it's probably going to affect one function on your part and you are producing valid JSON anyway. Surely you can bill a fortune 500 company for a function to put things in order.

[coldtea]

>I think my argument is a bit different -- sure, this is an interface (maybe to a COBOL copybook in this case?). And yes, it's not "JSON".

If it's not JSON, it's undefined when it uses JSON tools and libraries, and anything goes.

If it's not JSON, document it as your own dialect, and use your own tools, and try to never talk to the outside world based on it with systems that treat it as JSON.

>But I certainly have a lot of pause with the sentiment of "some idiot checked the JSON order checkbox on DataPower". My first thought is instead "I wonder why someone thought this was necessary."

It might not be, it could be the BS default setting...

[cat199]

Money down 3 months later:

1) the gateway or more likely something behind it starts crashing for memory errors when someone is serializing some stupidly large array into it

2) using ordered vs non-ordered keys on input changes the behavior and fixes it

3) enabling this checkbox to prevent it fixes the issue and guards against it happening again

4) everyone has forgotten about this web weenies inquiry into the issue

5) due to #4, it takes like 3 weeks of system crashes and hairy debugging to find the cause

6) this guy is long gone, having ridden off into the sunset of smugness

Also:

1) fixing the serialization-dependent memory allocation 4 layers deep on the back-end to allow things to operate safely without this checkbox requires a complex change to several other components and associated system-wide validation testing which would take: drumroll "9 people 6 months to complete"

2) What is the point of this javadoc reference and how exactly does it relate to the issue at hand? Here's a random code doc reference too!: https://pymotw.com/3/collections/ordereddict.html and here also a discussion about impacts: https://mail.python.org/pipermail/python-dev/2016-September/...

[coldtea]

Money down:

1) Nothing happened, this already went down years ago, as the author writes.

2) The setting was only stopping the BS IBM system layer, wasn't really needed elsewhere.

3) The BS setting was probably even default, e.g. not consciously enabled by someone for the specific system.

>What is the point of this javadoc reference and how exactly does it relate to the issue at hand?

The point is that the IBM system who had this setting was using that BS, brain-dead, not-JSON, implementation to handle the order, when the setting was enabled.