JDK-8176834 : jdk/nio/zipfs/MultiReleaseJarTest.java test fails after JDK-8176709
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2017-03-15
  • Updated: 2017-03-25
  • Resolved: 2017-03-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10 JDK 9
10Fixed 9 b162Fixed
Related Reports
Relates :  
JDK-8176709 - (zipfs) JarFileSystem::isMultiReleaseJar is incorrect
Relates :  
JDK-8176843 - Manifest not strictly implementing its specification
Description
The test fails with the following output:

[TestNG] Running:
  jdk/nio/zipfs/MultiReleaseJarTest.java

config MultiReleaseJarTest.initialize(): success
test MultiReleaseJarTest.testIntegers(-5, 8): success
test MultiReleaseJarTest.testIntegers(0, 8): success
test MultiReleaseJarTest.testIntegers(8, 8): success
test MultiReleaseJarTest.testIntegers(9, 9): success
test MultiReleaseJarTest.testIntegers(10, 10): success
test MultiReleaseJarTest.testIntegers(11, 10): success
test MultiReleaseJarTest.testIntegers(100, 10): success
test MultiReleaseJarTest.testIsMultiReleaseJar(): failure
java.lang.AssertionError: expected [true] but found [false]
	at org.testng.Assert.fail(Assert.java:94)
	at org.testng.Assert.failNotEquals(Assert.java:496)
	at org.testng.Assert.assertTrue(Assert.java:42)
	at org.testng.Assert.assertTrue(Assert.java:52)
	at MultiReleaseJarTest.testCustomMultiReleaseValue(MultiReleaseJarTest.java:221)
	at MultiReleaseJarTest.testIsMultiReleaseJar(MultiReleaseJarTest.java:196)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:547)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
	at org.testng.TestRunner.privateRun(TestRunner.java:773)
	at org.testng.TestRunner.run(TestRunner.java:623)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
	at org.testng.SuiteRunner.run(SuiteRunner.java:259)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
	at org.testng.TestNG.run(TestNG.java:1018)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:89)
	at jdk.internal.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:547)
	at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:230)
	at java.base/java.lang.Thread.run(Thread.java:844)
test MultiReleaseJarTest.testNewFileSystem(): success
test MultiReleaseJarTest.testShortJar(): success
test MultiReleaseJarTest.testStrings("runtime", 9): success
test MultiReleaseJarTest.testStrings("-20", 8): success
test MultiReleaseJarTest.testStrings("0", 8): success
test MultiReleaseJarTest.testStrings("8", 8): success
test MultiReleaseJarTest.testStrings("9", 9): success
test MultiReleaseJarTest.testStrings("10", 10): success
test MultiReleaseJarTest.testStrings("11", 10): success
test MultiReleaseJarTest.testStrings("50", 10): success
test MultiReleaseJarTest.testVersions(8, 8): success
test MultiReleaseJarTest.testVersions(9, 9): success
test MultiReleaseJarTest.testVersions(10, 10): success
test MultiReleaseJarTest.testVersions(11, 10): success
test MultiReleaseJarTest.testVersions(100, 10): success

The test was updated in JDK-8176709 with a couple of new test cases, and testCustomMultiReleaseValue("true\rOther: value", true) fails.
Comments
It appears the test is correct and uncovering a bug in Manifest. According to the specification then "\n", "\r\n" and "\r" should be valid newline strings, which this test was written to verify. Since this is pre-existing behavior I suggest we comment out the failing test case, testCustomMultiReleaseValue("true\r\Other: value", true), and file a bug to re-examine the Manifest implementation or specification in a later release.
15-03-2017
This indicates a discrepancy between how JarFile checks if there's a Multi-Release: true attribute in the manifest, and the way java.util.jar.Manifest reads these values. I'll investigate what's at fault here, but if Manifest parsing is sensitive to choice of line separator the code assumptions in JarFile might be too relaxed.
15-03-2017
The rest contains the following test cases: @Test + public void testIsMultiReleaseJar() throws Exception { + testCustomMultiReleaseValue("true", true); + testCustomMultiReleaseValue("true\r\nOther: value", true); + testCustomMultiReleaseValue("true\nOther: value", true); + testCustomMultiReleaseValue("true\rOther: value", true); ... private static final AtomicInteger JAR_COUNT = new AtomicInteger(0); + + private void testCustomMultiReleaseValue(String value, boolean expected) + throws Exception { If I understand correctly, testCustomMultiReleaseValue() builds a multi-release jar, and put "value" to "Multi-Release" attribute. Then, it checks if version/Version.java contains major version. Look like it doesn't contain major version for some reason. So, I am not sure if it's a bug in the test or JDK.
15-03-2017
Claes, Could you please take a look at it?
15-03-2017