[
https://issues.apache.org/jira/browse/COMPRESS-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16072408#comment-16072408
]
Simon Spero edited comment on COMPRESS-416 at 7/3/17 1:07 PM:
--------------------------------------------------------------
I think I mostly understand the issue now.
# There are three different formats in which Zip can store times
# Two of these formats will overflow around the year 2107-8
# JDK 9 transparently switches from using dos times or xtra dos times to using
NTFS times
# JDK 9 now switches over to NTFS times at the end of 2099.
# Since some of this logic is in the set code, there may be a bogus timestamp
stored.
# I haven't checked to see if the problem can happen with java utils
ZipInputStream on the same test file, or if the problem comes from
commons-compress. If the problem occurs using the test file with the java
libs, then it's definitely a jdk bug.
# If the test is hacked to say that xtended time is always used, the tests all
pass.
was (Author: sesuncedu):
I think I mostly understand the issue now.
# There are three different formats in which Zip can store times
# Two of these formats will overflow around the year 2107-8
# JDK 9 transparently switches from using dos times or xtra dos times to using
NTFS times
# JDK 9 now switches over to NTFS times at the end of 2099.
# Since some of this logic is in the set code, there may be a bogus timestamp
stored.
# I haven't checked to see if the problem can happen with java utils
ZipInputStream on the same test file, or if the problem comes from
commons-compress. If the problem occurs using the test file with the java
libs, then it's definitely a jdk bug.
# If the test is hacked to say that xtended time is always used, the tests all
pass.
# This may
> Tests failing under jdk 9 : one reflection issue, one change to ZipEntry
> related issue
> --------------------------------------------------------------------------------------
>
> Key: COMPRESS-416
> URL: https://issues.apache.org/jira/browse/COMPRESS-416
> Project: Commons Compress
> Issue Type: Bug
> Affects Versions: 1.14, 1.15
> Environment: JDK 9 ( jdk9 tree tip - I believe this is what will be
> the RC, or if not, what would have been RC).
> java.runtime.version = 9-internal+0-adhoc.ses.jdk9
> java.specification.version = 9
> java.version = 9-internal
> java.vm.specification.version = 9
> os.arch = amd64
> os.name = Linux
> os.version = 4.4.0-81-generic
> Reporter: Simon Spero
> Fix For: 1.15
>
> Attachments: surefire-reports.zip
>
>
> X5455_ExtendedTimestampTest is failing under JDK 9 , due to what appears to
> be a bogus value returned from getTime(). It seems like the test failure
> might be due to the changes introduced for this:
> https://bugs.openjdk.java.net/browse/JDK-8073497
> Tests were run using intelliJ TestRunner, using the openjdk9 build from the
> tip of the jdk9 tree (not dev). I believe that this is at most one commit
> away from what will be the RC (which was delayed at the last minute due to
> two issues, one of which was javadoc related, and the other hotspot.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
