This message continues the conversation I started with Johan in a random
GitHub issue. :-) I'm posting it to the mailing list so that anyone can
join the discussion with other questions or comments.
We're now using the github issue tracker to discuss reproducible builds, which
is probably not the primary reason Github issues were created, so I think it's
better to start this discussion on a mail thread :)
Agreed, and thanks for the suggestion. In general, I find it difficult
to stay silent when I witness situations like the following:
- Thomas Reinhardt having to do "a little digging" to determine which
JAR files are platform independent, when reproducible builds makes that
self-evident because they're identical no matter which platform built them.
- Reviewers having to figure out which refactoring might cause a
change in the compiled output, when reproducible builds lets them make
that distinction immediately.
- Developers having to be timid and unsure about changes to our build
system, when reproducible builds allows them be fearless and certain,
even with radical changes.
At a minimum, a reproducible build is a tool that makes some formerly
difficult tasks easy. At best, a reproducible build is a superpower that
reveals old bugs otherwise impossible to find.[1] Somewhere in the
middle, it gives us our best chance to detect the supply-chain attacks
that threaten a world increasingly dependent on software.
The majority of potential issues I see are on niche platforms with niche
usecases. Creating reproducible builds for all these platforms sounds extremely
difficult to me, but I'd like to be proven wrong.
That would be difficult, but that's not what we're doing. The goal is
not to make, for example, builds by Oracle and Gluon identical, nor
builds on Ubuntu 18.04, Ubuntu 20.04, and Raspberry Pi OS identical. The
goal is to allow each published build to be separately reproducible
using the same dependencies as the original build. So those
niche-platform corner cases are just additional builds, each one
reproducible in its own unique environment.
The goal of my pull request is even more modest: to allow any individual
or organization, and especially the Linux distributions, to create
reproducible builds of JavaFX. There's no plan to require reproducible
builds -- just to permit them. Oracle, though, has already made the
switch for the JDK. Builds of OpenJDK 20 and later will always create
reproducible builds. In making the change, Magnus Ihse Bursie wrote, "If
you were to ask me, the fact that compilers and build tools ever started
to produce non-deterministic output has been a bug from day one."[2] On
that point, I couldn't agree more.
John
[1] https://github.com/openjdk/jdk/pull/10070#issuecomment-1230888930
[2] https://github.com/openjdk/jdk/pull/9152#issue-1270543997
