FULL PRODUCT VERSION :
Java Plug-in 10.3.0.5
Using JRE version 1.7.0_03-b05 Java HotSpot(TM) Client VM
and
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)

REPRODUCIBILITY :
This bug can be reproduced often.

---------- BEGIN SOURCE ----------
 try
      {
         System.getProperty("user.home");
      
      }
      catch(AccessControlException securityEx)
      {
 
     }
---------- 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.
REGRESSION: No.