RFR: 8324672: Update jdk/java/time/tck/java/time/TCKInstant.java now() to be more robust

[Ramkumar Sunderbabu]

On Thu, 10 Oct 2024 15:12:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> If your objection is primarily on Math.abs, is this ok?
>> `
>>         long diff = test.toEpochMilli() - expected.toEpochMilli();
>>         assertTrue(diff >= 0 && diff < 10_000);  // less than 10 secs
>>  `
>
> I don't think there is any way to meaningfully and reliably test the assertion that `Instant.now()` is the using the same clock as `Instant.now(Clock.systemUTC())` given the potential delays in execution of the two statements.
> It might be possible to ignore well known delays due to gc or compilation by making sure the code is warmed up by repeating the test until the delta meets the .1 sec limit. If it was really a bug, the test would timeout after a couple of minutes. Putting a while loop around the body of the test would cover that.
> I'd leave the code using `abs` alone to avoid exposing some other unanticipated change.

I am keeping the timeout as 60 seconds. is this ok?

    @Test(timeOut=60000)
    public void now() {
        Instant expected, test;
        long diff;
        do {
            expected = Instant.now(Clock.systemUTC());
            test = Instant.now();
            diff = Math.abs(test.toEpochMilli() - expected.toEpochMilli());
        } while( diff > 100 ); // retry if more than 0.1 sec
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21413#discussion_r1795975497