Hi @fnuecke,

Thank you for your contribution! We really value the time you've taken to put this together.

Before we proceed with reviewing this pull request, please sign the Typesafe Contributors License Agreement:

http://typesafe.com/contribute/cla

Signed.

quick thoughts - 1) we should probably ensure the sort is locale-independent (Id have to research how) 2) sort can certainly change meaning in some cases; we will have to be careful about which those are. but since we don't preserve any defined order at all right now maybe we are good. 3) does this have to be a render option or maybe we just always do it? if we output in undefined order now then it doesn't seem to lose anything to always sort.

there's some other old conversation maybe on a bug or PR about using LinkedHashMap to always preserve order and I might like to find that to refresh memory on whether it interacts with this.

1. I'm pretty sure Collections.sort fulfills this requirement.
   From the documentation of Collections.sort:

Sorts the specified list into ascending order, according to the
natural ordering of its elements. All elements in the list must
implement the Comparable interface.

From the documentation of String.compareTo:

Compares two strings lexicographically.
The comparison is based on the Unicode value of each character in
the strings.

2. Hmm, I can't really think of a case where this could happen - since keys are unique there would be no overrides that could get messed up. But as you say, it's random now, anyway. Defaulting the setting to false and adding a clear warning concerning this in the documentation might be enough address this?

3. I don't know. But I remembered that one xkcd and went with the safe route.

Retaining the original order of the read config would be very much preferable to this approach, of course. I'll just be using this as a... workaround until that gets implemented :-)

The complicated situation (that makes retaining order kind of hard) is when there are merges; but those don't happen for SimpleConfigObject, only for ConfigDelayedMerge I guess, so changing SimpleConfigObject is safe and easy.

Reading the docs I agree that String.compareTo is good.

If you're amenable I'd like to make this the hardcoded behavior and not a render option, because I don't see why someone would want random rather than sorted. Care to update the patch so it just adds the sorting and not an option?

Preserving order might be nice (it just means switching to LinkedHashMap and then adding tests and ensuring we never reverse the list in our algorithms I guess), but it does seem like an empty gesture (and perhaps pointless extra cpu/memory) without also preserving comments and whitespace and generally "supporting" round trip load/save - which would be a lot of work. So I like your solution to just sort for now, at least it makes things a little more deterministic.

Thanks for messing with this.

Done! Just to clarify, Arrays.sort is what's used internally by Collections.sort, so there is no real change in logic on that part, just fewer collection type conversions.

Thanks!