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