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