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]

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.

thanks,
-sherman


> /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
>