Zip Extended Timestamp signedness changed in JDK9 but not JDK8

[Gary Gregory]

Hi Sherman,

Thank you for your reply.

My feel and experience around the Apache projects I am involved in is that
for Commons and perhaps others there is a sense of doom and frustration
around so many changes that are breaking "stuff". Modules break stuff,
reflection breaks stuff. Ok, changes are coming. The bottom line is that I
would like to be able to run in Java 9 without hacking. In the case of this
specific bug and uint32, it would be great if we could get to the point
where we could say: Run on Java 8 update X and Java 9 update Y and our code
does not have to change and passes our tests. This is my reason for wanting
the fix in Java 8. :-)

Gary

On Jul 4, 2017 16:36, "Xueming Shen" <xueming.shen at oracle.com> wrote:

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