On Thu, 10 Oct 2024 15:12:44 GMT, Roger Riggs <[email protected]> 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
