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

Mandy Chung mandy.chung at oracle.com
Thu Feb 26 16:34:52 UTC 2015


On 2/26/2015 12:30 AM, Joel Borggrén-Franck wrote:
> I realize now that this code will probably never have worked on other hypothetical implementations of Annotations.

This is what I was wondering when I see it expect
sun.reflect.annotation.AnnotationType.

> The problem is with the default method AnnotatedElement::getDeclaredAnnotationsByType. If someone has an external implementation of AnnotatedElement (and one of the lessons from adding these methods in 8 was that there are other implementations) then if that external implementation haven’t added getDeclaredAnnotationsByType they will call into our AnnotationSupport. This is all fine if that external representation of AnnotatedElement uses our representation of Annotations, with Proxies and all. But I suspect that the conditions that would end up taking the non-proxy code path in the patch, will already fail in the check:
>
>               AnnotationType annoType = AnnotationType.getInstance(containerClass);
>               if (annoType == null)
>                   throw invalidContainerException(container, null);
>
> So what is the best thing to do here if the annotation is not Proxy based and is coming from an implementation of the AnnotatedElement interface that we don’t control and that is missing the methods added in 8?

I did a quick search on my corpus and find only one reference to
sun.reflect.annotation.AnnotationType.  Looks like external implementation
doesn't get pass this.

> I think throwing here might be the best option, especially since we will probably already have failed in the AnnotationType.getInstance check.

I haven't studied closely the specification about support for alternate 
implementation.   One thing I would say is that if the implementation 
never works for alternate implementation, to fix JDK-8073056, I would 
simply remove line 207-218.   Perhaps file a new issue to follow up the 
support for alternate implementation if appropriate.

Mandy



More information about the core-libs-dev mailing list