Hi,
Not all properties file might benefit from being sorted in key ordering.
Think for instance about the logging.properties file - where you would
certainly want to keep the original ordering.
That said - we rarely store() a logging properties file, and if
we stored it, key might appear in random order anyway (due to
HashMap hashing) - so maybe that's OK after all...
As long as the build doesn't fiddle with these... :-)
cheers,
-- daniel
On 25/08/2021 15:06, Roger Riggs wrote:
Hi,
For the occasional human reader of a property file, a deterministic
order would make them
easier to use as well. The natural sort order of the keys as String
would be suitable.
I'd support changing the order written without changing the API. Load
and other readers
of property files have no expectation of an order; there is almost no
compatibility risk.
Providing an alternate timestamp (or no timestamp) would need a new method.
An overload of store(...) would be consistent with current uses.
To produce a compatible format, including a timezone, it would need to
be either
java.util.Date or java.time.ZonedDateTime.
(I'm not a fan of system properties that change API behavior).
Regards, Roger
