Hi Rafael,
Filed https://bugs.openjdk.org/browse/JDK-8392583 to track adding
support for the --env option to jpackage.
- Alexey
On 9/17/2026 2:30 PM, Rafael Winterhalter wrote:
Hei Alexey, good points and I would actually prefer the "env" option
as it will naturally reflect evolution and scope of the different
tools beneath. I can already work around most of today's limitations
by forking a process,
Hei Alexey,
good points and I would actually prefer the "env" option as it will
naturally reflect evolution and scope of the different tools beneath.
I can already work around most of today's limitations by forking a
process, it just seems like the tool api is half baked that way, so
I'd appreciate a different solution.
The jarsigner reproducability question is well known and
reproducability assertions normally drop those files. So those
inherent problems we will not solve, but we can get in the territory
where reproducability is understood, at least.
As for the jlink issue: it seems like it's being worked on already, so
hopefully those can be treated as seperate questions.
Thanks, Rafael
Alexey Semenyuk <[email protected]> schrieb am Do., 17. Sept.
2026, 18:00:
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
<https://urldefense.com/v3/__https://github.com/wixtoolset/issues/issues/8978__;!!ACWV5N9M2RV99hQ!OADzUT92rGU4aIkJ8F0y-R3r8x-NvmC9zs3v09Ib7TOvQgtEIxfcwRkISI7KlSAKrtNxpYX68w9pspcC83UpsPeb$>
- 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
