-
Bug
-
Resolution: Cannot Reproduce
-
P3
-
8u101, 9
FULL PRODUCT VERSION :
C:\Windows\System32>java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
C:\Windows\System32>ver
Microsoft Windows [Version 6.1.7601]
A DESCRIPTION OF THE PROBLEM :
This appears to be related to the fix for JDK bug https://bugs.openjdk.java.net/browse/JDK-8155076. The above seems to have been fixed but has caused this UnsupportedOperationException to occaisionally occur. We have not been able to firmly identify the root cause yet but believe it is due to the garbage collection of weak-references.
java.lang.UnsupportedOperationException: null
at java.util.Collections$UnmodifiableMap.remove(Unknown Source) ~[na:1.8.0_101]
at java.util.jar.Attributes.remove(Unknown Source) ~[na:1.8.0_101]
at com.sun.deploy.cache.CachedJarFile.getManifest(Unknown Source) ~[na:na]
at com.sun.deploy.security.DeployURLClassPath$JarLoader$2.getManifest(Unknown Source) ~[na:na]
at java.net.URLClassLoader.defineClass(Unknown Source) ~[na:1.8.0_101]
at java.net.URLClassLoader.access$100(Unknown Source) ~[na:1.8.0_101]
at java.net.URLClassLoader$1.run(Unknown Source) ~[na:1.8.0_101]
at java.net.URLClassLoader$1.run(Unknown Source) ~[na:1.8.0_101]
at java.security.AccessController.doPrivileged(Native Method) ~[na:1.8.0_101]
at java.net.URLClassLoader.findClass(Unknown Source) ~[na:1.8.0_101]
at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source) ~[na:na]
at java.lang.ClassLoader.loadClass(Unknown Source) ~[na:1.8.0_101]
at com.sun.jnlp.JNLPClassLoader.loadClass(Unknown Source) ~[na:na]
at java.lang.ClassLoader.loadClass(Unknown Source) ~[na:1.8.0_101]
Has occurred once in QA (but has not been reproducible), and 2 customers have reported it too since upgrading to 8u101.
REGRESSION. Last worked in version 8u91
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
We are still working to reproduce - will update this if/when we can. We believe the cause is related to garbage collection of the weak-reference (CachedJarFile.manifestRef).
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
CachedJarFile.getManifest should successfully return the manifest, not throw an exception.
ACTUAL -
java.lang.UnsupportedOperationException: null
at java.util.Collections$UnmodifiableMap.remove(Unknown Source) ~[na:1.8.0_101]
ERROR MESSAGES/STACK TRACES THAT OCCUR :
See above.
REPRODUCIBILITY :
This bug can be reproduced occasionally.
---------- BEGIN SOURCE ----------
Still working on this.
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Looking at preventing the garbage collection of the manifestRef by establishing a hard-link to it.
C:\Windows\System32>java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
C:\Windows\System32>ver
Microsoft Windows [Version 6.1.7601]
A DESCRIPTION OF THE PROBLEM :
This appears to be related to the fix for JDK bug https://bugs.openjdk.java.net/browse/JDK-8155076. The above seems to have been fixed but has caused this UnsupportedOperationException to occaisionally occur. We have not been able to firmly identify the root cause yet but believe it is due to the garbage collection of weak-references.
java.lang.UnsupportedOperationException: null
at java.util.Collections$UnmodifiableMap.remove(Unknown Source) ~[na:1.8.0_101]
at java.util.jar.Attributes.remove(Unknown Source) ~[na:1.8.0_101]
at com.sun.deploy.cache.CachedJarFile.getManifest(Unknown Source) ~[na:na]
at com.sun.deploy.security.DeployURLClassPath$JarLoader$2.getManifest(Unknown Source) ~[na:na]
at java.net.URLClassLoader.defineClass(Unknown Source) ~[na:1.8.0_101]
at java.net.URLClassLoader.access$100(Unknown Source) ~[na:1.8.0_101]
at java.net.URLClassLoader$1.run(Unknown Source) ~[na:1.8.0_101]
at java.net.URLClassLoader$1.run(Unknown Source) ~[na:1.8.0_101]
at java.security.AccessController.doPrivileged(Native Method) ~[na:1.8.0_101]
at java.net.URLClassLoader.findClass(Unknown Source) ~[na:1.8.0_101]
at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source) ~[na:na]
at java.lang.ClassLoader.loadClass(Unknown Source) ~[na:1.8.0_101]
at com.sun.jnlp.JNLPClassLoader.loadClass(Unknown Source) ~[na:na]
at java.lang.ClassLoader.loadClass(Unknown Source) ~[na:1.8.0_101]
Has occurred once in QA (but has not been reproducible), and 2 customers have reported it too since upgrading to 8u101.
REGRESSION. Last worked in version 8u91
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
We are still working to reproduce - will update this if/when we can. We believe the cause is related to garbage collection of the weak-reference (CachedJarFile.manifestRef).
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
CachedJarFile.getManifest should successfully return the manifest, not throw an exception.
ACTUAL -
java.lang.UnsupportedOperationException: null
at java.util.Collections$UnmodifiableMap.remove(Unknown Source) ~[na:1.8.0_101]
ERROR MESSAGES/STACK TRACES THAT OCCUR :
See above.
REPRODUCIBILITY :
This bug can be reproduced occasionally.
---------- BEGIN SOURCE ----------
Still working on this.
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Looking at preventing the garbage collection of the manifestRef by establishing a hard-link to it.
- duplicates
-
JDK-8192055 CachedJarFile.getManifest throws UnsupportedOperationException (Collections$UnmodifiableMap.remove)
- Closed
- relates to
-
JDK-8155076 Webstart loads JARs from MANIFEST.MF after loading the jars from resources-tag
- Closed