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 > > - 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 > >
