Zip Extended Timestamp signedness changed in JDK9 but not JDK8

[Gary Gregory]

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