On Thu, 5 Jun 2025 05:31:28 GMT, Volkan Yazici <vyaz...@openjdk.org> wrote:
>> test/jdk/java/net/HttpCookie/MaxAgeExpires.java line 67:
>>
>>> 65: new Test(-1, "Thu, 01 Jan 2024 00:00:00 GMT", 0, true),
>>> 66: new Test(1000, "Thu, 01 Jan 2024 00:00:00 GMT", 1000, false),
>>> 67: new Test(0, "Thu, 01 Jan 2024 00:00:00 GMT", 0, true),
>>
>> Maybe you could add a test case with maxAge=1000 and expires = set at the
>> current time + 500s. The expected maxAge would be 1000.
>>
>> Something like:
>>
>>
>> static final String NOW_PLUS_500 =
>> DateTimeFormatter.RFC_1123_DATE_TIME.format(
>> java.time.ZonedDateTime.ofInstant(Instant.now().plusSeconds(500),
>> ZoneId.of("UTC")));
>>
>> ...
>>
>>
>> new Test(1000, NOW_PLUS_500, 1000, false),
>>
>>
>> Ideally we'd like to test the same with maxAge = -1, but that could be
>> tricky since we can't know in advance the exact value that will be computed
>> for the new `maxAge`.
>
> Alternatively, we could create a `HttpCookie::parse` method<sup>1</sup>
> accepting a `long currentTimeMillis`, and precisely determine the expected
> value?
>
> <sup>1</sup> This can either be private and accessed via reflection, or
> package-private and accessed by placing the test in the same package.
I'll look into doing both of those. So long as we are immune to timing related
issues it seems reasonable. By the way, I will push an implementation update
first, which results from existing cookie regression failures.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2128885121
