[TOML] Order of input is not the order of output.

[Articdive]

I have a List that I'm outputting into my toml file.

I give it a,b,c,d in a LinkedList<> so it's definitely that order in the for loop (which just sets the path to said value), e.g "a" = "RandomNumber" and so on;
and the output I receive is:
b
c
a
d
and not
a
b
c
d

TLDR: Pretty much the set method isn't saving the order in which elements are set.

[TheElectronWill]

Config is based on HashMap which is unordered, that's why the order of config entries isn't guaranteed.

It's not a goal, for now (v3), to have ordered configs by default. However, you can still have them by wrapping a LinkedHashMap:

Config ordered = Config.wrap(new LinkedHashMap(), InMemoryFormat.defaultInstance());
// use whatever other ConfigFormat you need

[Articdive]

Alright, that works, thanks :)

[TheElectronWill]

@Articdive NightConfig v3.5.3 now offers a global setting to preserve the insertion order of values 😃

Config.setInsertionOrderPreserved(true);

All configurations created after this call will preserve the insertion order, except if created from a user-provided Map or Map supplier.

[mikehearn]

Why not just always preserve insertion order? Are there some fundamental reasons to not delete this option and have it always be true?

FWIW in Kotlin if you say val a = mapOf(....) then what you get is always a LinkedHashMap. They considered that the very small additional memory overhead is easily worth the saving in bugs and confusion due to pseudo-random reorderings.

[TheElectronWill]

You're right, it would be better to preserve the order by default. I must admit there is no real reason other than "that's how I've done it in NightConfig v1 so it stayed like this".

Besides, LinkedHashMap's performance is comparable to HashMap's. Adding this to my TODO for NightConfig v4 😃