RFR: JDK-8223536 jdk/javadoc/doclet/MetaTag/MetaTag.java still fails when run across midnight

Jonathan Gibbons jonathan.gibbons at oracle.com
Wed Jan 15 15:42:09 UTC 2020


Thanks.

-- Jon

On 1/15/20 5:51 AM, Pavel Rappo wrote:
> Three dates are created in succession: (1) `startDate` on MetaTag:103, (2) `startTime` on HtmlConfiguration:265, and `date`
> on MetaTag:95. If dates (1) and (3) are equal, we then conclude that (2) must be the same as (1) and (3). If I read the intent correctly, this implication warrants the conditional logic on MetaTag:96.
>
> This looks reasonable, provided we are not concerned with other date sorcery. Maybe one of these days we could switch to the more modern java.time API. Looks good to me.
>
> -Pavel
>
>> On 15 Jan 2020, at 00:23, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>>
>> Please review a fix for a problem that occurs when a test is run across midnight.
>>
>> Although it is difficult to confirm the root cause, and equally difficult to test, the root cause is believed to be a static final instance of java.util.Calendar that is used to obtain the date written into the generated files, and which is subsequently verified by tests. When javadoc is run multiple times in the same JVM, as will occur when running the MetaTag.java test, the static final Calendar may be initialized to a time that is outside the range checked by the test.
>>
>> The fix is to replace the static instance by a non-static instance created in HtmlConfiguration.
>>
>> The fix is noreg-hard, because it can only be fully tested by running within milliseconds of midnight. It's remarkable that this has actually occurred multiple times in productio build/test runs.
>>
>> -- Jon
>>
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8223536
>> Webrev: http://cr.openjdk.java.net/~jjg/8223536/webrev/
>>


More information about the javadoc-dev mailing list