Hi, Alan, the changes look fine to me.
A short quick question: what is the reason to introduce a new AWTPermissions class as a holder for various AWTPermission constants? We can have the same fields directly in AWTPermission. The only difference is that AWTPermission is in java.awt, while the new class is in sun.awt, but such a change seem to require a CCC request anyway...
Thanks, Artem On 12/10/2013 5:51 PM, Alan Bateman wrote:
In JDK 8 we deprecated the JDK 1.1-era SecurityManager methods checkTopLevelWindow, checkSystemClipboard and checkAccessAwtEventQueueAccess with a warning that they would be changed in a future release to check AllPermission. At the same time we changed the java.awt.Window and Toolkit methods to use checkPermission directly so that the legacy methods aren't used. The motive for all this is modules of course and the strong desire to remove the dependency on java.awt.AWTPermission. I'd like to get the second phase of this work into JDK 9 early to give every opportunity to find any potential issues. The second phase of this work changes the SecurityManager methods to check AllPermission and updates the implementation to remove the reflection hackery that was used to allow this code work without AWT being present (something that was needed for the profiles build). The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/8029886/webrev/ The main thing that I'd like to get agreement on is the wording for the updated methods and also agreement from the AWT group to move the permission constants to a new class sun.awt.AWTPermissions. -Alan.
