Three Pillars of Reproducible Builds

One of the most fun non-determinism bugs I have worked on was the result of using an associative container with the key type being a pointer (like a <i>std::map&lt;void*, int&gt;</i> or similar), and then iterating over this container.<p>Since the order and value of dynamically allocated pointers is non-deterministic, this resulted in diverging behaviour at some point.<p>Better be sure that all your tools used during the build don&#x27;t do this kind of thing as well.

These three aren&#x27;t enough, you also need to take care of not storing build timestamps, hostnames, timezones, sorting and more:<p><a href="https:&#x2F;&#x2F;reproducible-builds.org&#x2F;docs&#x2F;" rel="nofollow">https:&#x2F;&#x2F;reproducible-builds.org&#x2F;docs&#x2F;</a>

On the JVM, maven doesn’t make this particularly easy.<p>It’s possible to try to store dependencies locally instead of shared in a global m2 repository, but it’s difficult to stop maven from adding the current time in jars or wars…<p>It’s as if all the default settings are the opposite of what they should be for reproducible builds.<p>Any idea if there is a project to try to improve things with maven or with another JVM tool? (Grade, sbt, etc.)

How can you discuss this w&#x2F;o mentioning Nix (or the likes)?

I guess any stubs the compiler adds will also have to be reproducible, big whoop.