8371855: Time stamps are missing on zip bundles with gradle 9

[arapte]

Gradle 9 onwards, the Archive tasks (Jar, Ear, War, Zip, AbstractArchiveTask) produce reproducible archives by default

Under this change, there are two factors that affect our zip files.

1. Files have fixed timestamps (timestamps depends on the archive type).
2. File order in the archive is now deterministic.
   Especially the timestamp is a concern, the files now have a fixed timestamp i.e. 1 Feb 1980 instead of the creation date.

the gradle upgrading guide provides the solution on how to restore previous behavior. The fix picks 2 necessary flags.

Verified that for all files extracted from generated zip files:

1. Timestamp is now not fixed, and reflects the CREATION date.
2. The file permissions are unchanged.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author)

Issue

• JDK-8371855: Time stamps are missing on zip bundles with gradle 9 (Bug - P4)

Reviewers

• Kevin Rushforth (@kevinrushforth - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx.git pull/1993/head:pull/1993
$ git checkout pull/1993

Update a local copy of the PR:
$ git checkout pull/1993
$ git pull https://git.openjdk.org/jfx.git pull/1993/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1993

View PR using the GUI difftool:
$ git pr show -t 1993

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/1993.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back arapte! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[mlbridge]

Webrevs

• 00: Full (151c21ff)

[jgneff]

Why don't we instead start building JavaFX in a reproducible manner? I've been creating reproducible builds of JavaFX for years now (with the caveat of this bug). Those builds have over 2,000 active users without any reported problems. I set the following environment variable before calling gradlew:

# Sets the environment variable for reproducible builds
SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
export SOURCE_DATE_EPOCH

Doing so now can only help Johan's efforts to replace the Gradle build with its JDK-based alternative.

[kevinrushforth]

It isn't an either-or. Since we aren't going to require the setting of SOURCE_DATE_EPOCH, we need to fix the timestamps when it isn't set.

Separately, it would be a good idea to start using it for our builds. I'll file an RFE to do that. Perhaps it's worth considering for JavaFX 27 (so that we start using it early in the release cycle).

SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)

We wouldn't do it exactly as you suggest for a number of reasons, but as part of using it for our build, we would publish the SOURCE_DATE_EPOCH that we used.

@arapte Have you tested this with SOURCE_DATE_EPOCH to ensure no regressions in that mode?

Reviewers: @kevinrushforth @tiainen

/reviewers 2

[openjdk]

@kevinrushforth
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with at least 1 Reviewer, 1 Author).

[kevinrushforth]

All testing looks good, including with / without SOURCE_DATE_EPOCH.

Please confirm that you have done a CI build.

[arapte]

All testing looks good, including with / without SOURCE_DATE_EPOCH.

Thanks for testing with SOURCE_DATE_EPOCH, I had not done that.

Please confirm that you have done a CI build.

Yes Kevin, CI build completed successfully.