Hei Alan, thanks for the feedback and the pointer to the past discussion. The advantage of using Properties is that its contract is implicit with the object. It is not a problem to work around the limitations I mentioned, but the current gaps are so small that I still hoped this could be addressed in the JVM itself.
I agree that JSON might remove some of the need in the future, but as a simple, hand-editable format, properties still work surprisingly well, and I expect it to stay around even with a built-in JSON API. Many frameworks such as Spring also have native support for parsing configuration properties from these files, so a build tool might populate such files for assembled applications, for example by injecting version information and others. This is one scenario where I found that a build broke reproducibility. As for line separators, the discussion is similar. Build caches often store input independently of the hosting OS, and a step that generates a file like this is not obviously dependent on an OS, so it might be accidentally OS-dependent. Again, I understand that this is not a priority, but if you ever consider a minor brush up of a seasoned API, this one, I think, would bring some benefits. Best regards, Rafael Am Di., 15. Sept. 2026 um 11:17 Uhr schrieb Alan Bateman < [email protected]>: > 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 > > > >
