RFR: 8231640: (prop) Canonical property storage

[Jaikiran Pai]

On 07/09/21 9:02 pm, Alan Bateman wrote:
> On 07/09/2021 16:05, Roger Riggs wrote:
>> Hi,
>>
>> The value of SOURCE_DATE_EPOCH is not so sensitive that it needs the 
>> protections you are applying.
>> The doPriv only exposes the value of that specific environment 
>> variable and in the usual case, it is undefined.
>>
>> The complexity in the specification and implementation seem 
>> unnecessary in this case.
>
> I agree.  Given the complexity then it makes your suggestion/option to 
> just drop the date from the comment somewhat tempting.
>
> -Alan

I've now updated the PR to take into account the inputs that were 
provided so far. More specifically, the PR has been updated to:

  - remove the complexity around SecurityManager usage and now just uses 
a doPriveleged block to get the SOURCE_EPOCH_DATE.

  - use Arrays.sort(...) instead of a TreeMap to write out the sorted 
properties. This was a suggestion from Andrey and based on my JMH 
testing (which I will post separately), the Arrays.sort(...) did indeed 
perform better.

  - use DateTimeFormatter.RFC_1123_DATE_TIME while formatting and 
writing the reproducible SOURCE_DATE_EPOCH value. There isn't a general 
agreement yet on what format should be used. Stuart has suggested using 
a different format (the one in the debian patch). So this part of the 
change could still undergo further change.

  - use ZonedDateTime along with a DateTimeFormatter which matches the 
format used by java.util.Date.toString(), instead of using a 
java.util.Date() instance when writing out the current date.

The new tests that have been introduced in this PR have been adjusted to 
verify these new expectations. The existing and these new tests continue 
to pass with these changes.

-Jaikiran