[
https://issues.apache.org/jira/browse/COMPRESS-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14972416#comment-14972416
]
Stefan Bodewig commented on COMPRESS-326:
-----------------------------------------
I think I've tracked it down.
Traditionally Java's {{ZipEntry#getTime}} returned the {{astModifiedTime}} from
the archive entry's header directly - this is why we adjust the time to the
local time zone just like InfoZIP would do since the test archive has been
written by InfoZIP's zip.
Then came http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/90df6756406f which
changes the logic of {{ZipEntry#getTime}} and now uses additional time fields
InfoZIP or Microsoft's Compressed Folders feature would use in order to get a
better result. I haven't tracked down which Java8 update has been the first
one to receive the patch.
I'll try to adjust the test.
> Fix threading issue in X5455_ExtendedTimestampTest test class (a test for
> COMPRESS-210)
> ---------------------------------------------------------------------------------------
>
> Key: COMPRESS-326
> URL: https://issues.apache.org/jira/browse/COMPRESS-326
> Project: Commons Compress
> Issue Type: Bug
> Reporter: Konstantin Kolinko
>
> The test for COMPRESS-210 is currently failing when Compress is built at
> Apache Gump.
> http://vmgump.apache.org/gump/public/commons-compress/commons-compress-test/index.html
> It says that the last success was on 2015-10-06T00:00:09,
> it started failing at 2015-10-06T12:00:09
> and as of now the failure state is persistent for 22 runs (which means ~11
> days).
> The failure:
> {noformat}
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building Apache Commons Compress 1.11-SNAPSHOT
> [INFO]
> ------------------------------------------------------------------------
> <...>
> Running org.apache.commons.compress.archivers.zip.X5455_ExtendedTimestampTest
> Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.054 sec <<<
> FAILURE! - in
> org.apache.commons.compress.archivers.zip.X5455_ExtendedTimestampTest
> testSampleFile(org.apache.commons.compress.archivers.zip.X5455_ExtendedTimestampTest)
> Time elapsed: 0.027 sec <<< FAILURE!
> org.junit.ComparisonFailure: expected:<2105-01-01/0[0:00:02] +0000> but
> was:<2105-01-01/0[8:00:01] +0000>
> at org.junit.Assert.assertEquals(Assert.java:116)
> at org.junit.Assert.assertEquals(Assert.java:145)
> at
> org.apache.commons.compress.archivers.zip.X5455_ExtendedTimestampTest.testSampleFile(X5455_ExtendedTimestampTest.java:171)
> {noformat}
> Reviewing rhe code of the test class, its usage of `SimpleDateFormat
> DATE_FORMAT` field is wrong. The field is declared as "static". A
> SimpleDateFormat is not thread-safe, so it must not be shared between tests,
> as some testing configurations may run several tests in parallel.
> A simple fix will be to remove "static" from declaration of that field and
> its initialization block, so that each running instance of the test gets its
> own copy of SimpleDateFormat class.
> (I am not sure whether this bug is the actual cause of the test failure. I do
> not see any reconfigurations of test environment on 2015-10-06. *Update*:
> according to gump-general mailing list \[1], on Oct 06 the Java runtime used
> to run Gump was updated to the latest Java 8 release)
> \[1]
> http://mail-archives.apache.org/mod_mbox/gump-general/201510.mbox/%3C5613A448.8040109%40apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
