RFR: 8231640: (prop) Canonical property storage [v21]
jai.forums2013 at gmail.com
Tue Sep 21 04:04:42 UTC 2021
Thank you Joe. That link helped. I have now moved the CSR to the next state.
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.
> 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, for
>>>> At a high level - the `store()` APIs in `Properties` have been
>>>> modified to now look for the `SOURCE_DATE_EPOCH` environment
>>>> variable. 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()`
>>>> 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.
>>>>  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
More information about the core-libs-dev