java.util.Properties: reproducible write

[Jason Mehrens]

For store method, I wish it was:
1. Null comment, meant no comment and no date.
2. Empty comment, meant date only.
3. Not blank comment, meant comment line and date.

However, too late to change that behavior.

It would be nice if the JDK had a FilterWriter implementation that decorated a Writer to ignore all comments lines.  Properties itself could provide a factory method since it already knows about Writer.

Jason


________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Jaikiran Pai <jai.forums2013 at gmail.com>
Sent: Wednesday, November 27, 2024 1:34 AM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: java.util.Properties: reproducible write

Hello Rob,

On 27/11/24 12:52 am, Rob Spoor wrote:
> The comment provided in `store(Writer, String)` is added in addition
> to the date comment:
>
>         if (comments != null) {
>             writeComments(bw, comments);
>         }
>         writeDateComment(bw);
>
> The system property can be used to replace the date with a constant,
> but a) it's not possible to omit it because an empty property value
> still leads to the date being written,

The caller of Properties.store(Writer, String), if they pass null to the
comments parameter, then an attempt will be made to write out a comment.
The value for that comment will come from a system property named
java.properties.date. The value can be any free form text
https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/util/Properties.html#java.properties.date.
A blank (not empty) value can be set for that system property and that
will write out just whitespace as the comment line. Here's a test which
shows that usage
https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/Properties/StoreReproducibilityTest.java#L106.

> b) it's a global setting, not something to apply to a single
> Properties instance, and c) you need to set it when starting the JVM
> because its value is cached (tested in jshell).
>
> Perhaps adding an enum Properties.StoreProperties with single constant
> OMIT_DATE can be used:

The change to support reproducibility for Properties.store() went
through several rounds of discussions, including proposed overloads to
methods, before we settled on the current implementation. Some of those
discussions are here:

https://mail.openjdk.org/pipermail/core-libs-dev/2021-August/080758.html

https://mail.openjdk.org/pipermail/core-libs-dev/2021-September/081113.html

https://github.com/openjdk/jdk/pull/5372

-Jaikiran

>
>     // overload, not replacement; similar for OutputStream
>     public void store(Writer writer, String comments,
> StoreProperties... properties)
>
> This can then be called as props.store(writer, null,
> Properties.StoreProperties.OMIT_DATE).
>
>
> Rob
>
> On 26/11/2024 00:23, Roger Riggs wrote:
>> Hi Rafael,
>>
>> You might have missed the update added by JDK-8231640 <https://
>> bugs.openjdk.org/browse/JDK-8231640> Canonical property storage
>> The comment string can be provided either by a separate method
>> `store(Writer, String)` or by a system property.
>>
>> Regards, Roger
>>
>> On 11/25/24 4:53 PM, Rafael Winterhalter wrote:
>>> Hello,
>>>
>>> I find the java.util.Properties class to be quite convenient when
>>> writing minor collections of key-values. One unfortunate implication
>>> of the store method is that it always contains a comment line with
>>> the current date. The comment is never deserialized when loading the
>>> file, but the file hash is of course always changed, even if the
>>> content is identical at a later time. This can have unfortunate
>>> implications when the file hash is relevant to some form of cashing
>>> or validation mechanism.
>>>
>>> Would it be a good idea to add an overload that allows disabling the
>>> date comment? This would only require minimal code changes and the
>>> storage format would become reproducible. The key-values are already
>>> sorted by their key. The date can be fixed by a system property, but
>>> this is not always possible to define if the writer is not in
>>> control of the command line. Right now I have to reimplement the
>>> Properties::store method only to exclude this line.
>>>
>>> Thanks for your consideration and opinion,
>>> Rafael
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241203/cc3739b0/attachment.htm>