Hi Matthias, I have closed your bug JDK-8188901 in favor of the bug that Sherman had opened before: https://bugs.openjdk.java.net/browse/JDK-8188869.
Please post a webrev for the change as suggested by Claes. Thanks & Best regards Christoph > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On > Behalf Of Baesken, Matthias > Sent: Montag, 9. Oktober 2017 09:49 > To: core-libs-dev@openjdk.java.net > Subject: RE: jdk9/10 reject zip/jar files where seconds value of timestamp is > out of supported range 0 - 59 > > Hi Claes, thanks for your feedback. > > Hello, > I opened a bug : JDK-8188901 jdk9/10 reject zip/jar files where > seconds > value of timestamp is out of supported range 0 - 59 > > https://bugs.openjdk.java.net/browse/JDK-8188901 > > In case the dosToJavaTime change was to use java.time was really just a > cleanup, > I would like to submit a change and go back to Date, is that ok ? > > The suggested workaround by Xueming Shen > > >really wanted to suggest to just unzip/jar & jar those jar files again, > >as a workaround ... > > Is a good idea for some people, however in complex sceanarios people do > not even currently get the name of the archive in the exception . > So it is an issue to identify what to unpack/pack for them . > Another issue might be the usage of signed archives . > > > > Best regards, > Matthias > > > > > > Message: 2 > > Date: Fri, 6 Oct 2017 16:02:19 +0200 > > From: Claes Redestad <claes.redes...@oracle.com> > > To: core-libs-dev@openjdk.java.net > > Subject: Re: jdk9/10 reject zip/jar files where seconds value of > > timestamp is out of supported range 0 - 59 > > Message-ID: <e915d444-5f5f-0b88-649c-ef3c567d3...@oracle.com> > > Content-Type: text/plain; charset=utf-8; format=flowed > > > > Hi, > > > > it appears this is a difference where java.util.Date is carrying the > > overflow(s), while the > > java.time-based implementation is more strict.? Same issue assumedly > > exist for most > > fields in the dos format (minutes can be 0-63, hours 0-31, days 0-31...). > > > > The dosToJavaTime implementation was changed to use java.time mostly > as > > a cleanup > > (https://bugs.openjdk.java.net/browse/JDK-8066644), but this difference > > in strictness was > > overlooked.. > > > > Most compelling option for now might be to revert to the code in 8: > > > > ??? public static long dosToJavaTime8(long dtime) { > > ??????? @SuppressWarnings("deprecation") // Use of date constructor. > > ??????? Date d = new Date((int)(((dtime >> 25) & 0x7f) + 80), > > ????????????????????????? (int)(((dtime >> 21) & 0x0f) - 1), > > ????????????????????????? (int)((dtime >> 16) & 0x1f), > > ????????????????????????? (int)((dtime >> 11) & 0x1f), > > ????????????????????????? (int)((dtime >> 5) & 0x3f), > > ????????????????????????? (int)((dtime << 1) & 0x3e)); > > ??????? return d.getTime(); > > ??? } > > > > /Claes > > > > On 2017-10-06 14:24, Baesken, Matthias wrote: > > > Hello, > > > > > > When iterating on the zip entries (and printing the time stamps) of an > > > old > > sqljdbc.jar the exception > > > > > > "java.time.DateTimeException: Invalid value for SecondOfMinute (valid > > values 0 - 59): 60" > > > occured (issue has been seen on Windows). > > > > > > Looks like the dosToJavaTime function in ZipUtils.java of jdk9/jdk10 > > > is a > bit > > more "sensitive" > > > about the input it gets, compared to jdk8. > > > In both implementations : > > > > > > java.base/share/classes/java/util/zip/ZipUtils.java > > > jdk.zipfs/share/classes/jdk/nio/zipfs/ZipUtils.java > > > > > > > > > the computation of the "seconds" values is done by > > > > > > public static long dosToJavaTime(long dtime) { > > > ... > > > (int) ((dtime << 1) & 0x3e)); > > > ... > > > } > > > > > > 0x3e is binary 111110 or decimal 62, so larger values than the > > > supported > > maximum 59 can occur > > > (maybe only with old/problematic archives but still we had such an > > example). > > > > > > When looking a bit more closely into it, we found that the "second = 60" > > value was coming from a long value 930973758 > > > that was passed to ZipUtils.dosToJavaTime as dtime argument. > > > > > > (found this out by adding an enhanced chained exception to jdk9 > showing > > the dtime value passed to dosToJavaTime). > > > > > > Here is an example of the iteration on entries of such a "bad" zip file : > > > > > > C:\JVM\openjdk10\bin\java ZipIterate > > > > > > Iterate von ZipFile: > > > -------------------------------------- > > > name of > > ZipEntry:com/microsoft/sqlserver/jdbc/AppDTVImpl$SetValueOp.class > > > Exception in thread "main" java.time.DateTimeException: Invalid value > for > > SecondOfMinute (valid values 0 - 59): 60 > > > at > > > java.base/java.time.temporal.ValueRange.checkValidValue(ValueRange.java > > :311) > > > at > > > java.base/java.time.temporal.ChronoField.checkValidValue(ChronoField.jav > > a:714) > > > at java.base/java.time.LocalTime.of(LocalTime.java:322) > > > at java.base/java.time.LocalDateTime.of(LocalDateTime.java:337) > > > at > > > java.base/java.util.zip.ZipUtils.dosToJavaTime(ZipUtils.java:101) > > > at > > java.base/java.util.zip.ZipUtils.extendedDosToJavaTime(ZipUtils.java:114) > > > at java.base/java.util.zip.ZipEntry.getTime(ZipEntry.java:198) > > > at ZipIterate.main(ZipIterate.java:37) > > > > > > > > > > > > A similar problem (dealing with days/months not seconds out of > supported > > range) is described here : > > > https://bugs.openjdk.java.net/browse/JDK-8184940 > > > "JDK 9 rejects zip files where the modified day or month is 0" > > > > > > > > > Compared to jdk8, this is a regression so I think it would be good to > > > have > a > > better handling of problematic out of range seconds-values. > > > > > > Do you think it would be sufficient to adjust the out of range seconds to > > the supported max-value 59 ? > > > Or is something more sophisticated prefered ? > > > I found the enhanced chained exception showing the dtime long values > > helpful too, should I submit it ? > > > > > > Best regards, > > > Matthias > > > > > >
