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

[Jaikiran Pai]

Thank you Joe. That link helped. I have now moved the CSR to the next state.

-Jaikiran

On 21/09/21 9:28 am, Joseph D. Darcy wrote:
> Hello Jaikiran,
>
> The CSR is in Draft state. As discussed in the CSR wiki 
> (https://wiki.openjdk.java.net/display/csr/Main), the request needs to 
> be moved by the assignee to either Finalized or Proposed state to 
> request the CSR review the request.
>
> HTH,
>
> -Joe
>
> On 9/20/2021 8:46 PM, Jaikiran Pai wrote:
>> On Sat, 18 Sep 2021 03:52:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:
>>
>>>> The commit in this PR implements the proposal for enhancement that 
>>>> was discussed in the core-libs-dev mailing list recently[1], for 
>>>> https://bugs.openjdk.java.net/browse/JDK-8231640
>>>>
>>>> At a high level - the `store()` APIs in `Properties` have been 
>>>> modified to now look for the `SOURCE_DATE_EPOCH` environment 
>>>> variable[2]. If that env variable is set, then instead of writing 
>>>> out the current date time as a date comment, the `store()` APIs 
>>>> instead will use the value set for this env variable to parse it to 
>>>> a `Date` and write out the string form of such a date. The 
>>>> implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date 
>>>> format and `Locale.ROOT` to format and write out such a date. This 
>>>> should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is 
>>>> set. Furthermore, intentionally, no changes in the date format of 
>>>> the "current date" have been done.
>>>>
>>>> These  modified `store()` APIs work in the presence of the 
>>>> `SecurityManager` too. The caller is expected to have a read 
>>>> permission on the `SOURCE_DATE_EPOCH` environment variable. If the 
>>>> caller doesn't have that permission, then the implementation of 
>>>> these `store()` APIs will write out the "current date" and will 
>>>> ignore any value that has been set for the `SOURCE_DATE_EPOCH` env 
>>>> variable. This should allow for backward compatibility of existing 
>>>> applications, where, when they run under a `SecurityManager` and 
>>>> perhaps with an existing restrictive policy file, the presence of 
>>>> `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` 
>>>> APIs.
>>>>
>>>> The modified `store()` APIs will also ignore any value for 
>>>> `SOURCE_DATE_EPOCH` that  cannot be parsed to an `long` value. In 
>>>> such cases, the `store()` APIs will write out the "current date" 
>>>> and ignore the value set for this environment variable. No 
>>>> exceptions will be thrown for such invalid values. This is an 
>>>> additional backward compatibility precaution to prevent any rogue 
>>>> value for `SOURCE_DATE_EPOCH` from breaking applications.
>>>>
>>>> An additional change in the implementation of these `store()` APIs 
>>>> and unrelated to the date comment, is that these APIs will now 
>>>> write out the property keys in a deterministic order. The keys will 
>>>> be written out in the natural ordering as specified by 
>>>> `java.lang.String#compareTo()` API.
>>>>
>>>> The combination of the ordering of the property keys when written 
>>>> out and the usage of `SOURCE_DATE_EPOCH` environment value to 
>>>> determine the date comment should together allow for 
>>>> reproducibility of the output generated by these `store()` APIs.
>>>>
>>>> New jtreg test classes have been introduced to verify these 
>>>> changes. The primary focus of `PropertiesStoreTest` is the ordering 
>>>> aspects of the property keys that are written out. On the other 
>>>> hand `StoreReproducibilityTest` focuses on the reproducibility of 
>>>> the output generated by these APIs.  The `StoreReproducibilityTest` 
>>>> runs these tests both in the presence and absence of 
>>>> `SecurityManager`. Plus, in the presence of SecurityManager, it 
>>>> tests both the scenarios where the caller is granted the requisite 
>>>> permission and in other case not granted that permission.
>>>>
>>>> These new tests and existing tests under 
>>>> `test/jdk/java/util/Properties/` pass with these changes.
>>>>
>>>> [1] 
>>>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html
>>>> [2] https://reproducible-builds.org/specs/source-date-epoch/
>>> Jaikiran Pai has updated the pull request incrementally with one 
>>> additional commit since the last revision:
>>>
>>>    Roger's suggestion to reword the implSpec text
>> What would be the next step to move the CSR forward? Should I be 
>> changing it's status or do something else?
>>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/5372