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

Alan Bateman Alan.Bateman at oracle.com
Tue Jun 18 06:45:18 PDT 2013


I didn't see replies on this thread although I did chat with Artem 
briefly about the proposal.

To re-cap, the proposal is:

For jdk8:

1. Deprecate the 3 methods defined by SecurityManager with a warning  
that they will change in a future release to check AllPermission.
2. Change java.awt.Toolkit and java.awt.Window (spec + implementation) 
so that they check AWTPermission directly.

Future (maybe jdk9 project once that is open):

1. Change (spec+implementation) the 3 SecurityManager methods to check 
AllPermission.

The rational for doing this in two steps is allow for migration. These 
are JDK 1.0/1.1 era methods so we have to be careful. The change to 
Toolkit and Window is not strictly required to be done in 8 so I would 
be open to pushing these out to (to 9) if there is good reason.

I've put a webrev with the javadoc changes here (ignore the 
implementation for now):

http://cr.openjdk.java.net/~alanb/8008981/webrev/

At this point I want to get agreement on the API/spec changes. I also 
want to understand if there are any potential compatibility issues. As I 
mentioned in the first mail, then custom security managers that override 
checkTopLevelWindow, checkSystemClipboardAccess and checkTopLevelWindow 
will see a difference in that checkPermission will be called directly. 
Beyond that then I don't see an issues.

Thanks,

-Alan.



More information about the awt-dev mailing list