53

I have a JSON object which I have constructed within my Java program.

JSONObject jObj = {"AAA:aaa","BBB:bbb","CCC:ccc"}

I am sending this object to a server in which it expects the JSON object in the following type.

{"BBB:bbb", "AAA:aaa", "CCC:ccc"}

My question is that does the order of the JSON object really matters on the server side? If yes, how can I change the order?

Undo
  • 25,519
  • 37
  • 106
  • 129
Chanaka udaya
  • 5,134
  • 4
  • 27
  • 34
  • What is the problem you are facing? Any error or exception? – Juned Ahsan Jun 01 '13 at 07:56
  • 12
    The JSON RFC (RFC 4627) says that order of object members does not matter. – fge Jun 01 '13 at 08:05
  • 6
    Note to future self when Google brings me back here: MongoDB is sensitive to the ordering of keys when checking object equality. If you have a document with _id:{key1:"foo", key2:"bar"}, you will not find it with find({_id:{key2:"bar", key1:"foo"}}). – ahains Jun 05 '15 at 17:39
  • 2
    @ahains - note to you :-) MongoDB syntax not JSON ... strictly speaking. – Stephen C Oct 04 '18 at 12:46

5 Answers5

80

My question is that does the order of the JSON object really matters on the server side?

It should not matter. According to various JSON specifications, the order of the attributes is not significant. For example:

"An object is an unordered set of name/value pairs." (Source json.org)

"An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array." (Source RFC 7159)

Unfortunately, there are nitwits out there1 who ignore that aspect of the specs, and place some significance on the order of the attributes. (The mistake is usually made when there is a disconnect between the people specifying the APIs and those implementing them, and the people doing the specification work don't really understand JSON.)

Fortunately, the chances are that whoever designed / implemented the server didn't make that mistake. Most Java JSON parsers I've come across don't preserve the attribute order when parsing ... by default2. It would be hard to accidentally implement a server where the order of the JSON attributes being parsed was significant.

If yes, how can i change the order?

With difficulty, I fear:

  • You could generate the JSON by hand.
  • There is at least one JSON for java implementation3 that allows you to supply the Map object that holds a JSON object's attributes. If you use a LinkedHashMap or TreeMap, it should retain the insertion order or the lexical order of the attribute keys.

1 - For example, the nitwits that this poor developer was working for ... https://stackoverflow.com/a/4515863/139985

2 - RFC 7159 also says this: "JSON parsing libraries have been observed to differ as to whether or not they make the ordering of object members visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable in the sense that they will not be affected by these differences.". By my reading, this recommends that JSON libraries should hide any order of the pairs from application code.

3 - JSON-simple : https://code.google.com/p/json-simple/. There could be others too.

Community
  • 1
  • 1
Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • 3
    "There are nitwits out there" indeed. I'm here looking at code that parses JSON with .split(",") and then substring(). – KC Wong Feb 15 '19 at 01:14
  • You could add a JSON attribute listing the order of the JSON attributes in the order-managing data structure the JSON data is de-serialized into. Lots of coding fun and adding unit tests. – David Tonhofer May 13 '21 at 04:00
  • Yea, you could. But a more direct way representation is an JSON array of objects (or arrays) where each object (or array) represents an name / value pair. – Stephen C May 13 '21 at 05:26
  • 1
    The unordered structure is one of the worst mistakes in the JSON spec because in recursive structures it makes it expensive to impossible to implement efficient stream oriented data access. – Lothar Jun 03 '22 at 17:14
  • 1
    Interesting you say that. The order of keys in YAML is not significant either. So, perhaps people who need richer semantics from a serialization format should be looking for a different format? – Stephen C Jul 27 '22 at 13:31
11

IMHO not possible.

JSON docs says

An object is an unordered set of name/value pairs

So the way is getting the values in required order,rather than ordering json

Suresh Atta
  • 120,458
  • 37
  • 198
  • 307
2

You could use list assuming your server can accept it:

{"list": [ {"AAA":"aaa"},{"BBB":"bbb"},{"CCC":"ccc"}]}
Suresh Atta
  • 120,458
  • 37
  • 198
  • 307
1

The other answers rightly point out that the order should not matter. There are circumstances were the order may matter in a specific implementation that misunderstands the unordered nature of JSON.

For example say you want take a hash of the JSON string and store the hash for comparison against future hashes. The hash would be different if the order of the fields in the JSON string is not the same the next time you create the hash (even thought the data in the JSON string is the same).

This can happen if you're working with an API or a deserializer that returns JSON strings, with the fields in an inconsistent order.

This question more thoroughly discusses that issue and provides solutions to getting a consistent order JSON order mixed up

-5

The order of fields in a JSON object actually can matter. It depends on the serializer you are using. For example, when you serialize an inherited object you will get an extra JSON field called type=''. When you deserialize it the type field must come before any other JSON Field, otherwise it takes on the type of the parent.

  • 2
    you are describing a bug – Martijn Scheffer Apr 26 '19 at 13:11
  • 3
    I think if he mentioned where this happens (which serializer?), that would have been a valid answer. Bug or not, when one is trying to create a real life application, the truth in practice is more important than the claims on paper. – DraxDomax May 24 '19 at 10:34