JDK 8 (initial) RFR for JDK-8005294 : Consider default methods for additions to AnnotatedElement

Joel Borggrén-Franck joel.franck at oracle.com
Thu Oct 24 15:46:10 UTC 2013


Hi Peter, Joe,

On 24 okt 2013, at 22:10, Peter Levart <peter.levart at gmail.com> wrote:

> Hi Joe,
> 
> I see two problems with the implementation in AnnotatedElementSupport. The first is the treatment of declared-only annotations where the code returns either directly present or in-directly present repeatable annotations, but not both. So in the following example:
> 
> @Ann(1)
> @AnnCont({@Ann(2), @Ann(3)})
> 
> it will only return [@Ann(1)], but I think it should return all of them [@Ann(1), @Ann(2), @Ann(3)] - does the spec. define that?
> 

It does. If Ann is a repeatable annotation type then get[Declared]AnnotationsByType(Ann.class) should return all three. See 8misc.pdf bottom of page 20.

> The other is the treatment of "associated" annotations, where the AnnotatedElementSupport implementation has similar problem as the Andreas' 1st attempt of at fixing 8004912 for j.l.Class. It turns out that inherited repeating annotations can not be implemented in terms of Class.getAnnotation(Class), since this method aggregates together inherited and declared annotations not taking account of "equivalence" of two possible representations of repeating annotations (with or without the container) thus loosing the information about where in the hierarchy repeating annotations of a particular type are declared. See the following discussion:
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/022190.html
> 

I agree with this. It is also a problem in the spec part of the review.

> Otherwise I think that implementing AnnotatedElement.get[Declared]AnnotationsByType(Class) consistently at the very root of hierarchy is a good idea. If I'm not mistaken, only j.l.Class defines the difference between getDeclaredAnnotationsByType and getAnnotationsByType - all other AnnotatedElements don't implement inheritance and those two methods are equivalent for them. What about implementing only the "declared" aspect as equivalent default methods in AnnotatedElements, and overriding getAnnotationsByType in j.l.Class ?
> 

This sounds like a good idea. The default getAnnotatinosByType() should just be able to return getDeclaredAnnotationsByType().

cheers
/Joel

> Regards, Peter
> 
> On 10/24/2013 09:31 AM, Joe Darcy wrote:
>> Hello, 
>> 
>> Please review my initial implementation changes for 
>> 
>>     JDK-8005294 : Consider default methods for additions to AnnotatedElement 
>>     http://cr.openjdk.java.net/~darcy/8005294.0/ 
>> 
>> (Specification aspects of the review are taking place over at 
>> http://mail.openjdk.java.net/pipermail/enhanced-metadata-spec-discuss/2013-October/000279.html ) 
>> 
>> The webrev above is lacking tests. The basic testing approach I plan to take is: 
>> 
>> * Declare an AnnotedElementDelegate type in the test file 
>> * An AnnotedElementDelegate wraps an existing AnnotatedElement object, such as a java.lang.Class object or a java.lang.reflect.Method object. Abstract methods of the AnnotatedElement interface are sent to the base object; methods with defaults are run as defaults. 
>> * For annotation types including {null, PresentAnnotation, MissingAnnotation, RepeatableAnnotation, ...} the behavior of AnnotedElementDelegate.foo(arg) is compared for equality to baseAnnotatedElement.foo(arg). 
>> * Base annotated elements will include a Class object (where annotation inheritance can some input play) and a non-Class object. 
>> 
>> Thanks, 
>> 
>> -Joe 
>> 
> 




More information about the core-libs-dev mailing list