Proposal: Extending @Target
I'd like to share my idea of extendingjava.lang.annotation.Target
Here's an example that illustrates what I'm thinking of:
I have designed a classEnumerable that is a kind of "extendable enum" class, making it possible to register instances of a derived class with their superclass. (It is totally orthogonal to the java enum and has already proven valuable).
For this purpose, I came up with a tagging annotation that is declared as follows:
@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@interface RegisterAsSuperclass
{
}
Now, it would make a lot of sense to restrict the use of @RegisterAsSuperclass to types derived fromEnumerable.
This would be possible ifTarget were extended like this:
@Documented
@Retention(RUNTIME)
@Target(ANNOTATION_TYPE)
public @interface Target
@interface Target{
ElementType[] value();
Class<?> typeRestriction()default Object.class;
}
The second property "typeRestriction" would only apply if ElementType.TYPE is used. The compiler would be forced to reject compilation if a user-defined annotation is applied to a type not derived from the type specified. Thus, my sample annotation would become
@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target(value={ElementType.TYPE}, typeRestriction=Enumerable.class)
@interface RegisterAsSuperclass
{
}
What do you think?
[1950 byte] By [
McNeppa] at [2007-11-27 6:36:42]
# 1
Hi,
I have been having similar thoughts.
However I would do it by having another annotation
@interface TargetTypeRestriction {
Class<?> value() default Object.class;
}
used like this
@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@TargetTypeRestriction(Enumerable.class)
@interface RegisterAsSuperclass
{
}
You could then write an annotation processor that enforced this at compile time, generating an error if @RegisterAsSuperclass was used on Types that are subclasses of Enumerable.
Bruce
# 2
i definitely see the usefulness
sounds like a parameterized annotation, syntax option...
@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target(value={ElementType.TYPE})
@interface RegisterAsSuperclass<? extends Enumerable>
{
}
# 3
@interface RegisterAsSuperclass<? extends Enumerable>{} umm.No.
# 4
no? beyond the obvious syntax hurdles, it does convey the intent
this enforcement can be done without spec change
a viable alternative?
http://forum.java.sun.com/thread.jspa?threadID=5180814&tstart=0
musheno is discussing friend-like accessor protection in reply 30 http://forum.java.sun.com/thread.jspa?threadID=765960&start=30&tstart=0
could annotations benefit from such an idea? syntax to befriend an annotation?
Message was edited by:
developer_jbs
why not?
friend option
# 5
@Bruce:
Yes, I think you're right: implementing this with a new annotation and an AnnotationProcessor is the better way!
Plus, it leaves room for further improvement:
@interface TargetTypeRestriction {
Class<?> value(); // No default value here, since we woudn't use the Annotation if we wanted to restrict to Object.class
ElementType[] appliesTo() default {ElementType.TYPE};
}
I added an attribute "appliesTo", which would broaden the applicability of TargetTypeRestriction to ElementTypes other than TYPE.
If, for example, the Target annotation included ElementType.METHOD, applying the restriction would mean "can be used on methods of classes derived from a certain base"
It remains open, however, how one should deal with ElementType.FIELD: Should the restriction mean "can be used on fields that are members of restricted classes" or should it rather mean "can be used on fields of a restricted type"?
# 6
> Yes, I think you're right: implementing this with a
> new annotation and an AnnotationProcessor is the
> better way!
seems like a slippery slope
extending this view to extreme wouldn't it be inline to say: replace all modifiers, public, private, static, etc, and some keywords, e.g. extends, super, and generics syntax with annotations? aren't they only metadata for the compiler?
i like annotations and declarative programming but where do we draw the line? serious question here -- any thoughts
> Plus, it leaves room for further improvement:
a new keyword or syntax would not rule out improvement and could provide a more general solution
> I added an attribute "appliesTo", which would broaden
> the applicability of TargetTypeRestriction to
> ElementTypes other than TYPE.
> If, for example, the Target annotation included
> ElementType.METHOD, applying the restriction would
> mean "can be used on methods of classes derived
> from a certain base"
>
> It remains open, however, how one should deal with
> ElementType.FIELD: Should the restriction mean
> "can be used on fields that are members of
> restricted classes" or should it rather mean
> "can be used on fields of a restricted type"?
sounds like a need for a general solution
