toJSONObject does not maintain order.

[Othello280]

If utilizing XML.toJSONObject for marshaling the XML to a JSON string, the order of the elements in not maintained.

• Using XML.toJSONObject.toString

• JSONObject jSONObject = XML.toJSONObject(xmlString);
  String string = jSONObject.toString();

Recommend updating all HashMaps in JSONObject to LinkedHashMaps

[johnjaylward]

Please see the FAQ. This is already explained. By definition, JSON Objects are not ordered.

For any JSON implementation, you should not depend on they keys being ordered.

If you need to maintain order, we offer a JSONML class that may do what you need, but it uses JSON Arrays instead of objects and is not as easy to work with in my opinion.

[Othello280]

Thank you for the quick reply. Dealing with medical data, so the order is important. I will look into the JSONML.

[johnjaylward]

As this is open source, you always have the option to fork the project and change the backing hashmap to an ordered map if the JSONML doesn't work for you.

[Othello280]

I tested the LinkedHashMap and that worked great fro my need. Need to keep the arrays in order, so that the JSON appears with the arrays in the same order that the XML elements were.

<?xml version="1.0" encoding="UTF-8"?>
<Document 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <1 name= "Something1">
        <1Value>something1</1Value>
    </1>
    <2 name= "Something2">
        <2Value>something2</2Value>
    </2>
    <3 name= "Something3">
        <3Value>something3</3Value>
    </3>
</Document>

looks like:

{
    "Document": {
        "1": {
            "1Value": "something1",
            "name": "Something1"
        },
        "2": {
            "2Value": "something2",
            "name": "Something2"
        },
        "3": {
            "name": "Something3",
            "3Value": "something3"
        },
        "xmlns:xsi": "http://www.w3.org/2001/XMLSchema-instance"
    }
}

In small scale tests this is the result. But, for a large complex XML document the
JSON can be in any order, reversed in my case.
You can see the name space declaration at the bottom of the JSON.
I understand the choice in implementation, just pointing out the use case.

Updated Comment to reflect correct example

[raducoravu]

👍 For the same use case, right now I need to take the code and change the hash maps to linked hash maps, then recompile it. We need this for a JSON Format and Indent feature. We also have a feature in which we pass JSON to an XML tree-like structure, allow the end users to edit it and then go back to JSON. For both these cases the initial order of keys matters.
Maybe you could consider adding a setting for this.

[johnjaylward]

But order does not matter in JSON. If you are using JSON as a configuration holder, your users should not be editing the JSON directly in your app.

For the formatting, again, order does not matter. It is aesthetic only. Your end consumer in both cases should still work. If it doesn't, then you are using JSON wrong.

[raducoravu]

I know order does not matter for the final consumer of the JSON (usually the web browser Javascript engine). But if somebody manually creates and maintains a JSON file, it matters for them, for readability purpose they may want to keep the keys in a certain order.
Here's how we are using this particular library:

I work for Oxygen XML Editor, an editing tool which is mostly XML oriented but we also allow our end users to edit Javascript, JSON and so on.
When somebody opens the JSON in Oxygen, they can either edit it in the Text editing mode or in a "Grid" mode in which they see the JSON structure as a tree of nodes. In order to edit the JSON in the Grid mode we convert it to XML, it gets edited there and then we convert it back. And the end user expects the order of the keys to be the same.
I know this is probably not the initial purpose of the library, but this is how we are using it.

Changing from HashMap to LinkedHashMap will not break anything, it will also make automated tests more consistent because the internal order in which a hash set or map keeps its keys might change from one Java version to another and it would definitely improve these cases in which people pass from JSON to XML and back and expect minimal changes to their initial JSON.

[stleary]

@raducoravu your use case is appreciated, but ordering of JSON objects has been explicitly disallowed by the author of this project. See for example, issue #37. There are many other examples as well.

Hopefully, developers that need object ordering can fork the project and make the appropriate changes. Given the JSON-Java life cycle stage (maintenance mode, backwards compatibility prioritized), it should be safe to periodically merge the latest released code to forked projects.

[raducoravu]

@stleary I do not necessary agree with the decision but I understand, we are using a modified version of the project and I just wanted to provide our use case.