为什么不能在Java中扩展注释?

sin*_*pop 223 java inheritance annotations

我不明白为什么Java注释中没有继承,就像Java类一样.我认为这将非常有用.

例如:我想知道给定的注释是否是验证器.通过继承,我可以反复地浏览超类,以了解此注释是否扩展了ValidatorAnnotation.否则,我该怎样才能做到这一点?

那么,任何人都可以给我这个设计决定的理由吗?

ped*_*rce 162

关于它没有这样设计的原因你可以在JSR 175设计常见问题中找到答案,它说:

为什么不支持注释子类型(一个注释类型扩展另一个)?

它使注释类型系统复杂化,并且使编写"特定工具"变得更加困难.

...

"特定工具" - 查询任意外部程序的已知注释类型的程序.例如,存根发生器就属于这一类.这些程序将读取带注释的类而不将它们加载到虚拟机中,但会加载注释接口.

所以,是的,我想,原因是它只是KISS.无论如何,似乎这个问题(以及许多其他问题)正在作为JSR 308的一部分进行研究,你甚至可以找到一个已经由Mathias Ricken开发的具有此功能的替代编译器.

  • 好吧,也许我很愚蠢,但我觉得很遗憾只是为了"保持简单"而不能扩展注释.至少,Java设计者对类继承没有同样的看法:P (66认同)
  • Java 8 M7似乎不支持子类注释.太遗憾了. (2认同)
  • @assylias JEP 104不是要使子类注释成为可能.JEP 104是在Java 8中实现的,但是仍然无法对注释进行子类化(使一个注释扩展另一个注释). (2认同)

alp*_*ero 70

可扩展注释将有效地增加指定和维护另一种类型系统的负担.这将是一个相当独特的类型系统,因此您不能简单地应用OO类型范例.

在将多态性和继承引入注释时,请仔细考虑所有问题(例如,当子注释更改元注释规范(如保留)时会发生什么?)

所有这些增加了用例的复杂性?

您想知道给定的注释是否属于某个类别?

试试这个:

@Target(ElementType.ANNOTATION_TYPE)
public @interface Category {
    String category();
}

@Category(category="validator")
public @interface MyFooBarValidator {

}
Run Code Online (Sandbox Code Playgroud)

如您所见,您可以使用提供的工具轻松地对注释进行分组和分类,而不会造成过度的痛苦.

因此,KISS是不向Java语言引入元类型系统的原因.

[ps编辑]

我只使用String作为演示,并考虑到开放式元注释.对于您自己的给定项目,您显然可以使用类别类型的枚举,并为给定的注释指定多个类别("多重继承").请注意,这些值完全是假的,仅用于演示目的:

@Target(ElementType.ANNOTATION_TYPE)
public @interface Category {
    AnnotationCategory[] category();
}
public enum AnnotationCategory {
    GENERAL,
    SEMANTICS,
    VALIDATION,
    ETC
}

@Category(category={AnnotationCategory.GENERAL, AnnotationCategory.SEMANTICS})
public @interface FooBarAnnotation {

}
Run Code Online (Sandbox Code Playgroud)


Yis*_*hai 12

从某种意义上说,你已经拥有了Annotations - meta Annotations.如果使用元信息注释注释,则在许多方面等同于扩展其他接口.注释是接口,因此多态性并没有真正发挥作用,并且由于它们本质上是静态的,因此不能进行运行时动态调度.

在验证器示例中,您可以只在注释上获取带注释的类型,并查看它是否具有验证器元注释.

我可以看到继承有用的唯一用例是,如果你想能够通过超类型获得注释,但这会增加一大堆复杂性,因为给定的方法或类型可能有两个这样的注释,意味着必须返回一个数组而不是只返回一个对象.

所以我认为最终的答案是用例是深奥的,并且使更多标准用例复杂化,使其不值得.


Kon*_*hik 5

Java注释支持的设计者进行了许多"简化",损害了Java社区.

  1. 没有注释子类型会使许多复杂的注释变得不必要地丑陋.人们不能简单地在注释中具有可以容纳三件事之一的属性.一个人需要有三个独立的属性,这会使开发人员感到困惑,并且需要运行时验证以确保只使用三个中的一个.

  2. 每个站点只有一个给定类型的注释.这导致了完全不必要的集合注释模式.@Validation和@Validations,@ Image和@Images等

第二个是在Java 8中修复,但为时已晚.许多框架都是基于Java 5中可能的内容编写的,现在这些API疣在这里停留了很长时间.