8008793: SecurityManager.checkXXX behavior not specified for methods that check AWTPermission and AWT not present

Mandy Chung mandy.chung at oracle.com
Mon Feb 25 22:36:42 UTC 2013



On 2/25/2013 2:25 PM, Alan Bateman wrote:
> On 25/02/2013 22:07, Mandy Chung wrote:
>>
>> What you have is fine.  However, this means that the base module 
>> would need to require the desktop module for reflection.  I wonder if 
>> we could remove this reflective dependency from the base module.
>>
>> These methods were added in JDK 1.1 before 
>> SecurityManager.checkPermission was added (in 1.2).   Since they were 
>> defined and target for AWT to use, have you considered deprecating 
>> these 3 methods in JDK 8?  These methods are equivalent to call the 
>> SecurityManager.checkPermission method with the specific permission 
>> instance and the caller of these methods can call the checkPermission 
>> instead. In a future release, these checkXXX methods can then be 
>> changed to throw UnsupportedOperationException.  Since this is really 
>> a corner case, I think the compatibility risk would be minimal.
>>
>> Mandy
> The changes here are primarily for profiles.

Thumbs up from me with this change for profiles.

> For modules then we do need to sort out the remaining reflective 
> dependencies on desktop. I don't have a proposal on this yet, the main 
> issue is Bidi. For SecurityManager then changing these in jdk9 as you 
> suggest is a possible option.
>

Right. Bidi is the main issue.  IMO we should deprecate these 3 methods 
in JDK 8 to at least clean up the SecurityManager dependency as part of 
JEP 162 [1] and deal with other reflective dependencies separately.  
Anyway that is for modules and we can file a separate bug for it.

Mandy
[1] http://openjdk.java.net/jeps/162



More information about the security-dev mailing list