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

Roger Riggs rriggs at openjdk.org
Thu Oct 10 15:15:12 UTC 2024


On Wed, 9 Oct 2024 01:26:53 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Thanks @RogerRiggs for the comments. I increased the diff allowance to absorb any compilation related delays. What would you propose here?
>
> 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.

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

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


More information about the core-libs-dev mailing list