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

Anthony Petrov anthony.petrov at oracle.com
Wed Jun 19 06:07:43 PDT 2013

Hi Alan,

The spec changes that you propose look reasonable to me.

-- best regards, Anthony

On 06/18/2013 05:45 PM, Alan Bateman wrote:

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