Zip Extended Timestamp signedness changed in JDK9 but not JDK8

Xueming Shen xueming.shen at oracle.com
Tue Jul 4 20:26:43 UTC 2017


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



More information about the core-libs-dev mailing list