On Tue, 4 Apr 2023 15:46:20 GMT, John Neffenger <jgn...@openjdk.org> wrote:
>> This pull request allows for reproducible builds of JavaFX on Linux, macOS, >> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For >> example, the following commands create a reproducible build: >> >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives >> or the `jmod` tool itself has the required support. For more information on >> the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more >> information on the command to recreate the JMOD files, see the >> [`strip-nondeterminism`][2] repository. I'd like to propose that we allow >> for reproducible builds in JavaFX 17 and consider making them the default in >> JavaFX 18. >> >> #### Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module >> stores the time of the build. Furthermore, for builds that don't run on the >> Hudson continuous integration tool, the class adds the build time to the >> system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned >> by the file system. The native shared libraries also store their object >> files in the order returned by the file system. Most file systems, though, >> do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics >> module stores the absolute path of its `.css` input file in the >> corresponding `.bss` output file, which is then included in the JavaFX >> Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the >> first three sources of non-determinism. A later pull request can modify the >> Java files to fix the fourth. >> >> [1]: https://reproducible-builds.org/docs/source-date-epoch/ >> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > John Neffenger has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 21 commits: > > - Merge branch 'master' into allow-reproducible-builds > > Include two commits that fix WebKit build failures on Windows and macOS: > > 8282359: Intermittent WebKit build failure on Windows: > C1090: PDB API call failed, error code 23 > 8286089: Intermittent WebKit build failure on macOS in JavaScriptCore > - Merge branch 'master' into allow-reproducible-builds > - Support JDK 17 GA or later for building JavaFX > - Merge branch 'master' into allow-reproducible-builds > - Add '--date' argument for deterministic JMOD files > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - Comment out 'jmod --date' until building on JDK 19 > > Support for the 'jmod --date' option was added to JDK 19 starting > with the 19+2 early-access build, and it was backported to JDK 17 > starting with release 17.0.3. It is not available in JDK 18. > - Merge 'master' into allow-reproducible-builds > - Make minimal changes for new '--date' option > - ... and 11 more: https://git.openjdk.org/jfx/compare/810bd90d...e42a0709 Thanks for finding this, Kevin. For my own reference, the format of the Java version string is explained in the API specification of [Runtime.Version][1], which defines the `$OPT` additional build information as matching the regular expression `([-a-zA-Z0-9.]+)`. No colon characters are permitted. > We could consider a future RFE to adjust the format of the version string, > although I note that the JDK also adds the date code to the version string > only for developer builds. The JDK [removed the timestamp][2] in version 9 for [JDK-8170632][3], so now they look something like `20-internal+36-adhoc.root.build`. More to your point, I now see that the JDK also adds additional information by default, just like JavaFX. > No it doesn't. What it does mean is that they would need to set the following > properties to the same values that were used for the official build: Right. Sorry, I should have known that after all the "release" builds I do for this pull request! I would like to replace the current non-standard build timestamp with one that conforms to ISO 8601. This pull request uses the ISO 8601 *extended* format, but the standard also defines a *basic* format that does result in a valid Java version `OPT` field. [The consensus][4] seems to be that both the date and time must use the same format type, either extended or basic, which makes the current JavaFX build timestamp non-standard. [1]: https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/Runtime.Version.html [2]: https://github.com/openjdk/jdk/commit/e262ab65 [3]: https://bugs.openjdk.org/browse/JDK-8170632 [4]: https://stackoverflow.com/q/44870006 What do you think about simply replacing this pull request's extended format with the basic format? See the following sample program for details: import java.text.SimpleDateFormat; import java.time.Instant; import java.time.LocalDateTime; import java.time.ZoneOffset; import java.time.format.DateTimeFormatter; import java.time.temporal.ChronoUnit; import java.util.Date; public class Timestamp { private static final String OPT = "([-a-zA-Z0-9.]+)"; private static final String OK = " (okay)"; private static final String NOT_OK = " (NOT okay)"; public static void main(String[] args) { // ISO 8601 extended format var buildInstant = Instant.now().truncatedTo(ChronoUnit.SECONDS); String extended = buildInstant.toString(); // Non-standard format used in the current JavaFX release var buildDate = Date.from(buildInstant); var format = new SimpleDateFormat("yyyy-MM-dd-HHmmss"); String current = format.format(buildDate); // ISO 8601 basic format var localTime = LocalDateTime.ofInstant(buildInstant, ZoneOffset.UTC); var formatter = DateTimeFormatter.ofPattern("yyyyMMdd'T'HHmmss'Z'"); String basic = localTime.format(formatter); System.out.print("ISO 8601 extended format = " + extended); System.out.println(extended.matches(OPT) ? OK : NOT_OK); System.out.print("Current JavaFX format = " + current); System.out.println(current.matches(OPT) ? OK : NOT_OK); System.out.print("ISO 8601 basic format = " + basic); System.out.println(basic.matches(OPT) ? OK : NOT_OK); } } An example of its output is shown below: $ java Timestamp ISO 8601 extended format = 2023-04-06T04:20:16Z (NOT okay) Current JavaFX format = 2023-04-05-212016 (okay) ISO 8601 basic format = 20230406T042016Z (okay) ------------- PR Comment: https://git.openjdk.org/jfx/pull/446#issuecomment-1498506001
