Proposal: JDK-8231640 - (prop) Canonical property storage

[Roger Riggs]

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