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.s...@oracle.com
<mailto:xueming.s...@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.bate...@oracle.com <mailto: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
