RFR 8073056: Repeating annotations throws java.security.AccessControlException with a SecurityManager

Peter Levart peter.levart at gmail.com
Fri Feb 27 10:06:58 UTC 2015


On 02/27/2015 10:27 AM, Joel Borggrén-Franck wrote:
>> On 26 feb 2015, at 22:35, Peter Levart <peter.levart at gmail.com> wrote:
>> On 02/26/2015 10:27 PM, Peter Levart wrote:
>>> The m.setAccessible(true) for the methods is needed to access methods of non-public annotations, right? This call could be moved to AnnotationType constructor as there it will be performed only once per Method object.
>> ...which will have the added benefit in that it will guarantee that only one MethodAccessor object per Method will ever be constructed instead of two…
>>
> I don’t see this. setAccessible sets override in AccessibleObject, I don’t see a new MethodAccessor being generated here.

My fault! I was mistakenly thinking of Field objects in the context of 
setAccessible(boolean). If you use a Field object in two modes it will 
create and retain two different FieldAccessors (because they are 
different implementations in case field is final).

> But I agree with you, and setting it as accessible in the AnnotationType constructor should arguably be more secure since then we know it isn’t shared since we just got our copy fresh from getDeclaredMethods().

That's a good point from maintainability perspective, yes, if someone 
some time decides to "optimize" the AnnotationType. I think it would be 
nice if AnnotationType documents that members() method returns Method 
objects that are pre-conditioned with setAccessible(true) and that users 
should not change this flag.

Regards, Peter

> cheers
> /Joel




More information about the core-libs-dev mailing list