AWT impact of deprecating/changing SecurityManager#checkTopLevelWindow, checkSystemClipboardAccess, checkTopLevelWindow (original) (raw)

Alan Bateman Alan.Bateman at oracle.com
Fri Jun 14 09:52:01 PDT 2013

One of things that I'm thinking of proposing is to deprecate the checkTopLevelWindow, checkSystemClipboardAccess and checkTopLevelWindow methods that are defined by java.lang.SecurityManager. The motivation is modularity as these 3 methods have a specified dependency on java.awt.AWTPermission. For now we use reflection to avoid the static dependency but I would like to eliminate the dependency completely if we can. The other point is that these methods are completely obsolete and haven't really need needed since SecurityManager.checkPermission was added in JDK 1.2.

If deprecated then the proposal would be to change the 3 methods in some future release so that they are specified to check AllPermission rather than AWTPermission("xyz"). This would be consistent to how we have already changed these methods to work with compact Profiles of Java SE that do not have AWT.

I would like to explore the implications of this and specifically on the following AWT methods/constructors that are specified to involve these security manager methods:

java.awt.Toolkit.getSystemClipboard java.awt.Toolkit.getSystemSelection java.awt.Toolkit. getSystemEventQueue java.awt.Window(Frame) java.awt.Window(Window) java.awt.Winow.getWarningString()

Can anyone see any issues with changing the spec and implementation of these methods to use SecurityManager's checkPermission directly? The ultimate permission check would be the same as now so it shouldn't require anyone to adjust security policies.

Clearly custom security managers that override checkTopLevelWindow, checkSystemClipboardAccess and checkTopLevelWindow will see a difference in that checkPermission will be called directly. Also anyone depending on stack depth or anything fragile like that will break.

Thanks,

-Alan.

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20130614/0e404b98/attachment.html

More information about the awt-dev mailing list