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

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