RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v12]

John Neffenger jgneff at openjdk.org
Wed Apr 5 00:32:22 UTC 2023


On Tue, 4 Apr 2023 23:27:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I started doing some testing today.

Thank you, Kevin. I'm almost done with another round of my own testing and will post my results, too.

> 2. The format of `VersionInfo.BUILD_TIMESTAMP`, which is used in constructing the `javafx.runtime.version` System property for dev builds, has changed to an ISO date -- `2023-04-04T15:11:59Z` rather than `2023-04-04-151159`. Since the `:` is not legal for Java version strings, it is possible (though unlikely), that some app is parsing this in a way that might run into problems. This should probably be fixed.

It always bothered me that developer builds get a timestamp suffix while the official builds do not, even when built from the same Git tag. For example:


$ cat opt/javafx-sdk-20/lib/javafx.properties 
javafx.version=20
javafx.runtime.version=20+19
javafx.runtime.build=19
$ cat /snap/openjfx/current/sdk/lib/javafx.properties 
javafx.version=20
javafx.runtime.version=20+19-2023-03-07-164252
javafx.runtime.build=19


That makes it impossible for a developer to reproduce an identical copy of the official build.

Would it be more appropriate to use the output of `git describe`? For example, below is the command's output for this pull request branch and for the `20+11` tag:


$ git describe
21+11-25-ge42a070947
$ git describe allow-reproducible-builds 
21+11-25-ge42a070947
$ git describe 20+11
20+11


The JDK does something similar for its `release` file:


$ cat opt/jdk-20/release 
IMPLEMENTOR="Oracle Corporation"
JAVA_VERSION="20"
JAVA_VERSION_DATE="2023-03-21"
LIBC="gnu"
  ...
OS_ARCH="x86_64"
OS_NAME="Linux"
SOURCE=".:git:82749901b149"

-------------

PR Comment: https://git.openjdk.org/jfx/pull/446#issuecomment-1496766710


More information about the openjfx-dev mailing list