RFR: 8231640: (prop) Canonical property storage [v9]

[Roger Riggs]

Hi,

It does move the responsibility for that specific compatibility to the 
person defining the system property.
I would document it as conventionally having the date in the format 
expected.

In the context of a reproducible build, where the property is expected 
to be used, the builder would be
able to track down tools that were expecting a specific format and 
correct the input/property setting.

I think the incorrectly formatted string would be more use for tracking 
down a problem
than having the date be in the correct format but quietly different from 
what was expected.
(As is, an unparseable property value is replaced by the current date).

Roger


On 9/10/21 10:40 AM, Jaikiran Pai wrote:
>
> On 10/09/21 7:59 pm, Roger Riggs wrote:
>> On Fri, 10 Sep 2021 10:15:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:
>> I'm inclined to agree with Magnus, supplying the property as a 
>> string, avoids hardcoding details that are not really in the domain 
>> of Properties.  It opens up the option to omit the date and 
>> simplifies the code and spec.
>> Since the tools exist at build time or in the setting of the property 
>> to format it as needed, Properties does not need to.
>>
>> If non-null and non-empty it would be inserted as a comment. The 
>> string would not contain the "# " prefix.
>
> However, that goes against one of the goals this PR is trying to 
> achieve of backward compatibility of these existing store() APIs. 
> Allowing a free form text will mean that someone can feed a "foo bar" 
> and we will end up writing that as a comment, which essentially means 
> that the stored properties file no longer has any date comment. 
> Another example is, someone feeds a valid formatted text date to this 
> system property but that format doesn't match the format that is 
> advertized till date (the one which Date.toString() uses).
>
> Are we willing to allow that?
>
> -Jaikiran
>
>