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 <j...@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