Discussion: Reproducible builds

[John Neffenger]

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