FULL PRODUCT VERSION :
Java Plug-in 10.3.0.5
Using JRE version 1.7.0_03-b05 Java HotSpot(TM) Client VM
JRE version 1.7.0_04
ADDITIONAL OS VERSION INFORMATION :
Windows 7 32 bit
A DESCRIPTION OF THE PROBLEM :
I am running a applet and one of the class is reading use.home (System.getProperty("user.home");)
This code is executing this code few times and it is throwing AccessControlException on irregular interval .
It working most of the time and it fails sporadically and it lead to the application crash.
It is not reproducible with JRE1.6 and 1.5
REGRESSION. Last worked in version 6u31
ERROR MESSAGES/STACK TRACES THAT OCCUR :
ava.security.AccessControlException: access denied ("java.util.PropertyPermission" "user.home" "read")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
at java.lang.System.getProperty(Unknown Source)
at com.documentum.web.applet.ucfinvoker.LaunchRuntimeDelegate.init(Unknown Source)
at com.documentum.web.applet.ucfinvoker.LaunchRuntime.init(Unknown Source)
at com.sun.deploy.uitoolkit.impl.awt.AWTAppletAdapter.init(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
This bug can be reproduced often.
---------- BEGIN SOURCE ----------
---------- END SOURCE ----------
SHORT SUMMARY: When several signed applets are simultaneously loaded
from the same web page, some of them may not get full permissions.
INDICATORS: Different kinds of AccessControlException's that are not
supposed to be thrown for signed applets (for example, on reading
"user.home" property, or on accessing a local file system).
TRIGGERS: The problem happens sporadically and have symptoms of
a race condition with low-to-medium failure rate.
KNOWN WORKAROUND: Though there is no direct relation between this change
and the problem's root cause, disabling the Java Deployment Cache helps
to avoid the problem.
PRESENT SINCE: Introduction of plugin2, at least.
HOW TO VERIFY: There is no stand-alone test case for this issue.
The customer verifies the provided binaries in their environment
and informs us about the verification results.