<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