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