Hi Rafael,
This looks fairly straightforward for Linux, but less so for Windows and
macOS packaging.
For Windows MSI packages, it may be feasible. There is already a request
for WiX to support reproducible builds [1].
On macOS, I do not think this is feasible with the standard packaging
tools. Once signing is taken into account, it is definitely not feasible.
So the best we could have:
- fully supported for Linux packaging
- possibly fully supported for Windows packaging
- unsupported for macOS packaging
Even on Linux, as you noted, it will not work until jlink can create
reproducible images. This can be worked around by giving jpackage an
external runtime instead of letting it run jlink, but that narrows the
scope of the feature even further.
That said, I think it is premature to add it to jpackage.
Spawning a separate jpackage process just to pass the SOURCE_DATE_EPOCH
environment variable to dpkg-deb highlights a different limitation:
jpackage cannot pass environment variables to the tools it invokes.
I think we could address that by adding an --env option to jpackage:
jpackage ... --env SOURCE_DATE_EPOCH=1789611548 --env FOO
"--env" will help with Debian packaging. As for rpm packaging, you can
pass to jpackage a custom spec with additional defines in the resource
directory.
[1] https://github.com/wixtoolset/issues/issues/8978
- Alexey
On 9/17/2026 2:10 AM, Rafael Winterhalter wrote:
Hei,
jar and jmod got --date in JDK 19 and javadoc has -notimestamp, but
jpackage has nothing comparable, so the packages it builds differ on every
run. Would you be open to adding a --date option, or a -notimestamp switch?
jpackage could pass it on to the tools it drives. dpkg-deb already honours
SOURCE_DATE_EPOCH, and rpmbuild does too once a few macros are defined,
which jpackage could add next to the --define arguments it already passes.
With those set by hand and the same runtime image, two runs gave me
identical .deb and .rpm files.
Setting SOURCE_DATE_EPOCH yourself works from a shell, but not when
jpackage runs through the ToolProvider API: a call cannot be given its own
environment, so a build tool has to fork jpackage instead. An option would
behave the same either way.
The option could be documented to be a best effort. I understand that not
all targets might support this.
The bundled runtime image is not reproducible yet either, see JDK-8392531.
Thanks,
Rafael
