Towards cleaner nesting
joe.darcy at oracle.com
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