<AWT Dev> 8029886: Change SecurityManager check{TopLevelWindow, SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
Artem Ananiev
artem.ananiev at oracle.com
Wed Dec 11 13:17:53 UTC 2013
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.
More information about the security-dev
mailing list