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

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,

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