-
Bug
-
Resolution: Invalid
-
None
-
Minecraft 1.14.1
-
None
-
Windows 10 64bit and Debian Linux 64bit with various versions of Java:
Over a number of years of my servers existence (using server configuration git history), I see branches showing server.properties shifting between various combinations of the following JVMs
* OpenJDK 8, 10, 11, 12, 13EA
* GraalVM 19 (technically Java 8)
* Oracle Java 8
Note: Many of these configurations remained in testing but all demonstrate the issue and highlight that the order often changes as new properties added or hash-ordering changes.Windows 10 64bit and Debian Linux 64bit with various versions of Java: Over a number of years of my servers existence (using server configuration git history), I see branches showing server.properties shifting between various combinations of the following JVMs * OpenJDK 8, 10, 11, 12, 13EA * GraalVM 19 (technically Java 8) * Oracle Java 8 Note: Many of these configurations remained in testing but all demonstrate the issue and highlight that the order often changes as new properties added or hash-ordering changes.
-
Unconfirmed
-
(Unassigned)
Please consistently manage the server.properties order by writing all property keys in case-insensitive alpha-numeric order.
Problem Description
Every time Minecraft Java Edition starts it rewrites the server.properties file, with the output containing timestamp comments and settings as consumed by the server.
While it isn't ideal at all to be rewriting configuration (do those timestamp really belong in there), the main issue is that you cannot compare configuration because the order can change.
It appears that minecraft is writing properties in 'hashCode' order. Unfortunately this order changes between Java versions. This order is not sensible to the primary producer of these properties - the server administrator.
In addition, for servers that version their configuration, this means a manual comparison since diffs provided by source-control tools cannot help with showing the material differences.
History
This appears to have been raised in MC-26781 in 2013 and claimed to be resolved in 2016 (though it hasn't ever been resolved). It is linked to MC-9385 but this appears to be unrelated to the original bug or this request (other than maybe a developer might decide to tackle both at once).