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

[Kevin Rushforth]

On Mon, 1 Dec 2025 10:27:10 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Gradle 9 onwards, the [Archive tasks (Jar, Ear, War, Zip, AbstractArchiveTask) produce reproducible archives by default](https://docs.gradle.org/current/userguide/upgrading_major_version_9.html#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](https://docs.gradle.org/current/userguide/upgrading_major_version_9.html#reproducible_archives_by_default) 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.

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

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1993#issuecomment-3597566723