<AWT Dev> AWT impact of deprecating/changing SecurityManager#checkTopLevelWindow, checkSystemClipboardAccess, checkTopLevelWindow
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:
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the awt-dev