<AWT Dev> AWT impact of deprecating/changing SecurityManager#checkTopLevelWindow, checkSystemClipboardAccess, checkTopLevelWindow

[Alan Bateman]

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