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.gibb...@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/
