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:07:39 UTC 2013


On 2/25/2013 7:52 AM, Alan Bateman wrote:
> On 25/02/2013 15:22, Sean Mullan wrote:
>>
>> Yes, good point, but Alan has corrected that, refresh the webrev.
>>
>> I just had one comment:
>>
>> - I think you need to run the test in it's own JVM, since it sets an SM.
>>
>> --Sean
>>
> Yes, Tom is right and the checkPermissions in these methods should 
> succeed if AllPermission is granted. I should have replied to my 
> original mail to clarify this as I also noticed this when generating 
> the javadoc diffs after the mail.
>
> In any case, this is really a corner case because I wouldn't expect 
> these methods to be invoked by anything outside of AWT (or something 
> using AWT).

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



More information about the security-dev mailing list