We have a class 3 code signing certificate from verisign and are seeing this issue with 1.6.0_24. We have not had an issue previously. For paranoia's sake we re-signed the applet's jar with 1.6.0_24 and it made no difference. We are seeing a java.security.AccessControlException: access denied (java.awt.AWTPermission listenToAllAWTEvents) as well.
Explicitly adding an entry to java.policy is a workaround, but it's not terribly feasible given we have customers worldwide.
I'm not saying that you all are incorrect in calling this a bug, but keep one thing in mind: Java is under new management. Sun was very strict in keeping backwards compatibility; I wouldn't be surprised if Oracle takes the policy of security first, compatibility second.
Of course it would be nice if such things are documented.
My applet is a signed client / server applet. We download the applet to the user's hard drive so that the application can be run in an "offline" mode.
I was looking at our <applet> specifications and our applet <param> specification.
We use <param name="codebase" to point where the applet was installed on the hard drive. If I comment out the "codebase", the applet runs fine.
Correct if I'm wrong, but eliminating the "codebase" then tells Java to go look for that jar file, on the server, where the current HTML page was served from. Our jar file, that we download, just so happens to be in the same directory.
So ... with Update 24, execution is not a problem when loading and running the applet from the server, but trying to load and run the applet from the hard drive is now a problem which previously was not a problem. This definitely breaks our need for our users to run "offline"
For the life of me, I can't find anything in the "changes" to Update 24 that would explain why this is happening or why they would consider this type of execution a security concern.