Ordering/Sorting concerns for the library have existed coming up on a decade now.

Issues:

• ConfigImpl doesn't respect key order #35
• Reading config properties in order they appear in file #235
• Config depends on HashMap ordering causing breakage in Java 8 #253
• Unwrapped() should preserve the keys insertion orders #364
• Keep config item order in ConfigObject #365
• Keep same sort order #377
• [Feature Request] Unsorted serialized output #624

Pull Requests:

• Added ConfigRenderOptions entry for value sorting in objects. #138
• Sort keys alphanumerically. #229
• Apply numeric sort to object keys when rendering #266
• Render option to sort keys #557

There have been many discussions weighing the benefits and drawbacks of these features, but no real outcome on a proper solution.

A few points of discussion:

Render Sorting

Some changes over the years have resulted in some kind of weird behaviour, especially #228.

The ability for deterministic rendering of the config object was added in #138, but the part where you could optionally decide how you want this to be done was gutted in b38e708 for no actual reason??

With how widely used and with such great extensibility potential for this library, it feels wrong to have such an impactful feature hardcoded with zero ability to modify it (not even with reflection) due to it's inline usage.

Adding back the ability to toggle sorting + the ability to individually choose what sorting to use per render would offer much higher levels of extensibility, while effecting no other functionality.

ex. Sorting keys based on custom defined order.

order = ["first", "second", "last"]

conf = config {
  first=0
  second=1
  last=2
}

// default output
conf.render => 
first=0
last=2
second=1

// possible output
conf.render(sort: Comparator.comparingInt(order::indexOf)) =>
first=0
second=1
last=2

Ordering

Everywhere within the library, ordering of keys is completely arbitrary due to the nature of the map implementation used HashMap.

This creates non deterministic behaviour in reading configs.

Some points brought up in the past seem to not make sense, ex:

Meaningful order doesn't play well with the way the library works in general. Note that even if Config was ordered, your call to entrySet there would trash the order (because Set isn't ordered either).

The Sets returned by sorted/ordered maps are all custom and preserve iteration order based on the maps contracts. That is, after all the entire point of those map implementations...

I feel like 8 years later would be a perfect time to actually attempt to come up with a solution to the presented issues with merging. I am more than happy to help prototype potential solutions.

Please address this.