On Fri, 7 Apr 2023 06:22:05 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 incrementally with one additional 
> commit since the last revision:
> 
>   Revert format of timestamp in version OPT field

For the record, here's the latest version of my program that tests the 
timestamp formats:


import java.time.Instant;
import java.time.LocalDateTime;
import java.time.ZoneOffset;
import java.time.ZonedDateTime;
import java.time.format.DateTimeFormatter;
import java.time.temporal.ChronoUnit;

public class Timestamp {

    private static final String OPT = "([-a-zA-Z0-9.]+)";
    private static final String OK = " (OK)";
    private static final String NOT_OK = " (FAILED)";

    public static void main(String[] args) {
        var buildInstant = Instant.now().truncatedTo(ChronoUnit.SECONDS);

        // Creates the timestamp in the ISO 8601 extended format
        String extended = buildInstant.toString();

        // Creates the timestamp in the current non-stnadard format
        var zonedTime = ZonedDateTime.ofInstant(buildInstant, ZoneOffset.UTC);
        var currentFormatter = DateTimeFormatter.ofPattern("yyyy-MM-dd-HHmmss");
        String current = zonedTime.format(currentFormatter);

        // Creates the timestamp in the ISO 8601 basic format
        zonedTime = ZonedDateTime.ofInstant(buildInstant, ZoneOffset.UTC);
        var basicFormatter = DateTimeFormatter.ofPattern("yyyyMMdd'T'HHmmssX");
        String basic = zonedTime.format(basicFormatter);

        // Prints the timestamps and checks them for the version OPT field
        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);
        System.out.println();

        // Parses the timestamp in the ISO 8601 extended format
        zonedTime = ZonedDateTime.parse(extended);
        System.out.println("Parsed extended time = " + zonedTime);

        // Parses the timestamp in the current non-standard format
        var localTime = LocalDateTime.parse(current, currentFormatter);
        System.out.println("Parsed current time  = " + localTime);

        // Parses the timestamp in the ISO 8601 basic format
        zonedTime = ZonedDateTime.parse(basic, basicFormatter);
        System.out.println("Parsed basic time    = " + zonedTime);
    }
}


Below is a sample of its output:


$ java Timestamp
ISO 8601 extended format = 2023-04-07T16:01:16Z (FAILED)
Current JavaFX format    = 2023-04-07-160116 (OK)
ISO 8601 basic format    = 20230407T160116Z (OK)

Parsed extended time = 2023-04-07T16:01:16Z
Parsed current time  = 2023-04-07T16:01:16
Parsed basic time    = 2023-04-07T16:01:16Z

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

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

Reply via email to