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
