RFR JDK-8130914: java/util/zip/TestExtraTime.java fails with "java.lang.RuntimeException: setTime should make getLastModifiedTime return the specified instant: 3078282244456 got: 3078282244455"

Xueming Shen xueming.shen at oracle.com
Thu Jul 16 17:04:31 UTC 2015

On 07/15/2015 03:33 PM, Claes Redestad wrote:
> Code change looks OK to me, but perhaps there should be an explicit long conversion somewhere around the getYear() part ('d.getYear() - 1980 << 25L') of the expressions to deal properly with even larger values?

The spec of the dos time has the up limit, it should not beyond 32-bit. It was
not a problem when anything number overflows into up 32-bit before we tried
to utilize the up bits for the < 2000ms bits.

> Are there added tests missing from the updated TestExtraTime? I guess this is an intermittent issue, but it looks odd to update the test without adding some explicit test that provoke this issue.

It appears this existing test can easily catch the bug, so I just add the bugid to indicate that
this regression test can be used for that particular bug.


> /Claes
> Xueming Shen <xueming.shen at oracle.com> skrev: (15 juli 2015 21:10:39 CEST)
>     Hi,
>     Please help review the change for JDK-8130914.
>     issue:https://bugs.openjdk.java.net/browse/JDK-8130914
>     webrev:http://cr.openjdk.java.net/~sherman/8130914  <http://cr.openjdk.java.net/%7Esherman/8130914>/
>     This is a "regression" triggered by
>     https://bugs.openjdk.java.net/browse/JDK-8130914
>     http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.6  <http://cr.openjdk.java.net/%7Eredestad/jdk9/8073497/webrev.6>/
>     In which the change is to utilize a high 32-bit of the time value to store
>     <  2000 ms time piece. It appears the offending timestamp (year 2067...)
>     triggers the 32-bit "overflow" when converting java time to a 32-bit dos
>     time.
>     Thanks,
>     -Sherman

More information about the core-libs-dev mailing list