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.bate...@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
