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
On 8/25/21 8:51 AM, Alan Bateman wrote:
On 24/08/2021 15:07, Jaikiran Pai wrote:
The java.util.Properties class allows the properties to be written
out to a stream or through a writer. In its current form, the
specification of these APIs state that a comment comprising of the
current date is always written out. The spec doesn't make any
guarantees about the order of the properties when they are written out.
There have been requests asking to make these APIs more
deterministic. These requests, from what I have seen, mainly ask for:
- A way to disable writing out the date comment
- A way to write out the properties in a deterministic and
reproducible way
There have been discussions in the mailing list in the past which
have been captured in JDK-8231640[1]. In these discussions, there has
been an inclination to not touch the current existing API
implementations and instead introduce new API(s) to achieve the
proposed use cases.
Before starting off with an implementation, I wanted to try and get
some inputs on what the new API(s) would look like and what the scope
of such a work should be.
Another possibility is to add an overload of store that adds a
java.time.Instant argument for the timestamp. It could be specified as
Instant.EPOCH where reproducibility is required.
Magnus brings up the possibility of specifying that the store methods
look for SOURCE_DATE_EPOCH. As it happens, someone tried that [1].
With a spec change and the correct implementation then it should be
feasible option to explore.
We touched on the ordering issue in the jdk-dev discussion in 2019. I
think that can be changed to write in sorted key order without a spec
change, although it could be a useful property to specify.
-Alan
[1] https://bugs.openjdk.java.net/browse/JDK-8272157
