Towards cleaner nesting

Joe Darcy joe.darcy at
Tue Jan 28 04:00:03 UTC 2020

Catching up on email...

On 1/10/2020 1:43 PM, Brian Goetz wrote:


>>>> - annotation types can't directly contain things prohibited in 
>>>> interfaces, or instance/local methods (maybe)
>>>   - currently annos cannot have fields, default methods, or static 
>>> methods -- this still seems a reasonable restriction.
>> Why? I mean, I don't really care all that much, but if we're removing 
>> ad hoc restrictions, this one (no methods) certainly seems ad hoc. We 
>> don't even need new syntax.
> Because annotations are supposed to be pure metadata.  These things 
> all pull state and behavior into something that is supposed to be pure 
> metadata.   I mean, sure, I can imagine a world that blurs the 
> distinction between annotations and interfaces, but I'm not seeing 
> these restrictions as _gratuitous_; they were made deliberately.
The design center of usage of annotations assumes the identity of Class 
objects can be used to distinguish different annotation types via 
AnnotatedElement.getAnnotation​(Class<T> annotationClass). In a class 
file, an annotation type is identified by name and a runtime lookup 
occurs to convert the name to a class object. A known limitation of the 
API is the absence of a mechanism to provide a class loader to mediate 
this lookup (JDK-6537080). This may interact with plans to remove nested 
restrictions on annotation types.



More information about the amber-spec-experts mailing list