Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Mon, 3 Jul 2017 13:08:00 +0000 (UTC)
From: "Simon Spero (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.13083540.1498759919000.159354.1499087280472@Atlassian.JIRA>
In-Reply-To: <JIRA.13083540.1498759919000@Atlassian.JIRA>
References: <JIRA.13083540.1498759919000@Atlassian.JIRA> <JIRA.13083540.1498759919270@jira-lw-us.apache.org>
Subject: [jira] [Commented] (COMPRESS-416) Tests failing under jdk 9 : one
 reflection issue, one change to ZipEntry related issue
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 03 Jul 2017 13:08:08 -0000


    [ https://issues.apache.org/jira/browse/COMPRESS-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16072408#comment-16072408 ] 

Simon Spero commented on COMPRESS-416:
--------------------------------------

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)