jsp界面自动生成文件注释

jsp界面自动生成文件注释_实施注释界面

jsp界面自动生成文件注释

对于Java开发人员而言，每天都需要使用注释。如果没有其他简单的@Override注释，那该响了。创建注释要复杂一些。在运行时通过反射使用“自制”注释或在编译时调用注释处理器也是一种复杂性。但是我们很少“实现”注释接口。暗中有人在幕后一定为我们做。

当我们有注释时：

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface AnnoWithDefMethod {String value() default "default value string";
}

然后用这个注解注解的类

@AnnoWithDefMethod("my default value")
public class AnnotatedClass {
}

最后我们在运行时执行期间获取注释时

AnnoWithDefMethod awdm = AnnotatedClass.class.getAnnotation(AnnoWithDefMethod.class);

那么我们如何进入变量awdm呢？它是一个对象。对象是类的实例，而不是接口。这意味着Java运行时的幕后人员已经“实现”了注释接口。我们甚至可以打印出对象的特征：

System.out.println(awdm.value());System.out.println(Integer.toHexString(System.identityHashCode(awdm)));System.out.println(awdm.getClass());System.out.println(awdm.annotationType());for (Method m : awdm.getClass().getDeclaredMethods()) {System.out.println(m.getName());}

得到类似的结果

my default value
60e53b93
class com.sun.proxy.$Proxy1
interface AnnoWithDefMethod
value
equals
toString
hashCode
annotationType

因此，我们不需要实现注释接口，但是如果需要的话，可以实现。但是我们为什么要那样？到目前为止，我遇到了一种解决方案：配置guice依赖项注入。

Guice是Google的DI容器。绑定的配置以说明性方式作为Java代码提供，如文档页面中所述。您可以将类型绑定到实现，只需声明

bind(TransactionLog.class).to(DatabaseTransactionLog.class);

这样，所有注入的TransactionLog实例将属于DatabaseTransactionLog 。如果要在代码的不同字段中注入不同的注入，则应以某种方式向Guice发出信号，例如创建注释，将注释放在字段或构造函数参数上并声明

bind(CreditCardProcessor.class).annotatedWith(PayPal.class).to(PayPalCreditCardProcessor.class);

这要求PayPal作为注释接口，并且您需要编写一个新的注释接口，以与每个CreditCardProcessor实现或更多实现相伴，以便您可以在绑定配置中用信号通知和分离实现类型。仅有太多的注释类，这可能是一个过大的杀伤力。

除此之外，您还可以使用名称。您可以使用注解@Named("CheckoutPorcessing")注释注入目标并配置绑定

bind(CreditCardProcessor.class).annotatedWith(Names.named("CheckoutProcessing")).to(CheckoutCreditCardProcessor.class);

这是众所周知的技术，已广泛用于DI容器中。您指定类型（接口），创建实现，最后使用名称定义绑定类型。这样做没有问题，只不过在您键入处理而不是处理时很难注意到。在绑定（运行时）失败之前，此类错误将一直隐藏。您不能简单地使用final static String来保存实际值，因为它不能用作注释参数。您可以在绑定定义中使用这样的常量字段，但是它仍然是重复的。

这个想法是使用其他东西代替String。编译器检查的内容。显而易见的选择是使用一个类。要实现该代码，可以从NamedImpl的代码中学习，该代码是实现注释接口的类。代码是这样的（注意： Klass是这里未列出的注释接口。）：

class KlassImpl implements Klass {Class<? extends Annotation> annotationType() {return Klass.class}static Klass klass(Class value){return new KlassImpl(value: value)}public boolean equals(Object o) {if(!(o instanceof Klass)) {return false;}Klass other = (Klass)o;return this.value.equals(other.value());}public int hashCode() {return 127 * "value".hashCode() ^ value.hashCode();}Class value@OverrideClass value() {return value}
}

实际的绑定看起来像

@Injectpublic RealBillingService(@Klass(CheckoutProcessing.class) CreditCardProcessor processor,TransactionLog transactionLog) {...}bind(CreditCardProcessor.class).annotatedWith(Klass.klass(CheckoutProcessing.class)).to(CheckoutCreditCardProcessor.class);

在这种情况下，编译器很可能会发现任何错字。幕后实际上发生了什么，为什么我们要求实现注释接口？

配置绑定后，我们提供一个对象。调用Klass.klass(CheckoutProcessing.class)将创建一个实例KlassImpl当吉斯试图决定是否实际绑定配置有效结合CheckoutCreditCardProcessor到CreditCardProcessor论点的构造RealBillingService它只是调用该方法equals()上注释对象。如果Java运行时创建的实例（请记住Java运行时创建的实例的名称类似于class com.sun.proxy.$Proxy1 ），并且我们提供的实例相等，那么将使用绑定配置，否则必须进行其他绑定比赛。

还有另一个问题。实现equals()是不够的。您可能（并且，如果您是Java程序员（这就是为什么您还要读这篇文章（您当然不是Lisp程序员）），那么您也应该）记住，如果重写equals()还必须重写hashCode() 。实际上，您应该提供一个与Java运行时创建的类进行相同计算的实现。这样做的原因是，该比较可能不会直接由应用程序执行。 Guice可能（确实）正在从Map查找注释对象。在那种情况下，哈希码用于标识比较对象必须所在的存储桶，之后使用equals()方法检查身份。如果在创建Java运行时的情况下hashCode()方法返回的数字不同，则out对象将无法匹配。 equals()将返回true，但不会为它们调用它，因为在映射中找不到该对象。

方法hashCode的实际算法在接口java.lang.annotation的文档中描述。我以前看过此文档，但了解我第一次使用Guice并实现类似的注释接口实现类时定义算法的原因。

最后一件事是该类还必须实现annotationType() 。为什么？如果我知道了，我会写。