Zip Extended Timestamp signedness changed in JDK9 but not JDK8

[Xueming Shen]

There are two issues here.

(1) to fix/support the possible unix timestamp year 2038  issue when 
that extra timestamp(s) is used;
(2) to backport the fix to 8u.

I would assume the direct trigger of "wasting a meaningful amount of 
time ..." is (1) ?
Sure the root cause is we did not address year 2038 issue at first place 
when we added the extra
timestamp support in jdk8. My apology :-)

Btw, the changeset Simon mentioned/sited actually does not fix the 
issue. It actually will expose
the issue on year 2038 with the signed 32-bit int (it now follows the 
specification, which says the
timestamp is an uint32). The real fix is the changeset for #8161942.

https://bugs.openjdk.java.net/browse/JDK-8161942

Sure, we can backport it if desired. My original assumption is that this 
is something can wait, until
there is an escalation/real need ... we might have one now :-)

Sherman

On 7/4/17, 2:05 PM, Gary Gregory wrote:
> At the end of the day, my experience over at Apache Commons is that 
> these kinds of bugs waste a meaningful amount of time even if they may 
> not become an application level bug in the future. The bug wastes time 
> now...
>
> Gary
>
> On Jul 4, 2017 13:27, "Xueming Shen" <xueming.shen at oracle.com 
> <mailto:xueming.shen at oracle.com>> wrote:
>
>     Simon,
>
>     I would assume it's reasonable to believe 2037/2107 problem is NOT
>     going to be a critical issue
>     for jdk8u, given the fact we are talking about the "timestamp" of
>     a zip entry. I meant I'm pretty
>     much sure jdk8u will not be around :-) when we have any real 2037
>     entry timestamp, sure we
>     do/can have test cases for such issue. That said, I think we can
>     squeeze in a patch to address
>     this issue when we are adding other relatively "critical"
>     patch(s), if such fix is really desired.
>
>     -Sherman
>
>     On 7/4/17, 7:25 AM, Simon Spero wrote:
>
>         There was a fair degree of backporting of zip timestamp code,
>         but the
>         bugfix to (signed vs unsigned) didn't make it.
>         The corner cases that aren't handled are not-handled consistently.
>
>         On Mon, Jul 3, 2017 at 4:09 PM, Alan
>         Bateman<Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>>
>         wrote:
>
>
>             On 03/07/2017 20:05, Simon Spero wrote:
>
>                 :
>
>                 It is strange that this wasn't backported to jdk8u,
>                 since other changes to
>                 zip rom around the same time  are present.  Also, this
>                 fix doesn't seem to
>                 be mentioned in JIRA or the release notes.
>
>                 There were API changes as part of this update so not
>                 appropriate to
>
>             backport. More generally, the zip code has changed
>             significantly in JDK 9
>             to replace native implementation. I think the highest
>             priority is to make
>             sure that there aren't any corner cases that were handled
>             in 8 but not
>             handled in 9.
>
>             -Alan
>
>