On 12/09/2026 07:04, Rafael Winterhalter wrote:
Hei,
Properties is a handy lightweight key-value store that ships with the JDK,
but its store() output still cannot be made reproducible from the API.
Since JDK-8231640 the entries are sorted, and java.properties.date can
replace the timestamp comment. But that property is resolved through
StaticProperty, so it has to be set on the command line and affects the
entire VM, and an empty value falls back to the current date, so the
comment cannot be dropped at all. A library or build tool cannot make its
own store() calls deterministic without dictating how the process is
launched.
The second issue is the line separator. store0 ends lines with
BufferedWriter.newLine(), so the same properties differ byte for byte
between Windows and Linux.
An overload with options would cover both:
store(Writer, String comments, Set<StoreOption> options)
store(OutputStream, String comments, Set<StoreOption> options)
with values like NO_DATE_COMMENT and LF_LINE_SEPARATOR, current behaviour
as the default. The change to store0 is small.
While at it, preserving insertion order the way the SequencedMap additions
do would be nice for round-tripping hand-edited files, though I realise
Hashtable makes that a different discussion.
Would such a change be welcome? I am of course happy to file it and write
the patch.
This topic has come up a few times over the years.Here's the discussion
on JDK-8231640 that should give the context as to why the implementation
was changed to write in natural sort order of the keys, and why a
standard system property (rather than API) was introduced to configure
the date:
https://mail.openjdk.org/pipermail/core-libs-dev/2021-August/080758.html
Using a system property is okay for build tools but problematic (as you
note) if tools are invoked "in-process" (with ToolProvider for example).
I don't recall the issue of the line separator coming up in previous
discussions. The "reproducible builds" topic usually means same source
code and build environment so it might be a stretch to expect builds on
different platforms to produce identical bits.
One thing to point out is that Properties <: Map and there the store
methods doesn't too anything magic or sophisticated. Code that wants to
produce properties without a date command can easily do this itself. I
don't know if your need involves code that you control or some
dependency that uses Properties.store.
I agree that an overload of the store method that takes a
java.time.Instant looks useful now. At the same time I think we should
assume there will be some additions in the future. The JSON API is an
incubating API for JDK 28 and will likely become a permanent API in the
future future. I think we should expect there will be interest in
storing properties at JSON. Hard to know if the answer will be an
overload of store or if a new API shape will be used to deal with the 3
formats that it would specify at that time. Needs to be kept in mind so
avoid introducing something now that would be legacy if the API evolves.
-Alan
