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

[Anthony Petrov]

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.
>