这篇文章既介绍一个技术,又记录一个逐渐探索发现的过程,以供大家参考。

缘起

注意到Java的依赖注入DI规范(起初以为是CDI规范,然后发现是DI规范)有个叫@Qualifier的注解,用于当一个interface或base class有多个实现类时,能选择其中一个实现。如不用这一注解,一般的(按类型)注入就会报错说“不知道要在多个实现中选哪一个”。这一注解可以放在一个自定义注解上(例如@MyPreferredImplementation),从而将自定义注解变成一个qualifier annotation(限定符注解),然后只要在某一个实现类上放上这个自定义注解,也在注入处放上这个自定义注解,就能起到连通双方的作用,指定注入这个实现类了,很方便也很语义化。(大家可以搜索学习@Qualifier的教程。)

Spring支持DI规范,而它自己也有一个叫@Qualifier注解(包名不相同,在spring的package里),不但支持以上功能,还可以直接放在待注入的变量上,用name参数(例如@Qualifier(name = “myBeanName”))来指定要注入的那个实现类的bean name。Spring的这个功能好像更常用,至少在某公司就是这样,DI规范的qualifier功能反而有些不为人所知了。

我认为DI规范的更好,更加语义化。而这种把一个注解放在另一个注解上,是什么Java特性呢?起初不知道正确的关键词,用“annotation on annotation”之类的词语左查右查也查不到。然后看JDK的Javadoc,看哪一个呢,看已知的几个“annotation on annotation”,懂的朋友可能想到了,@Retention @Target @Inherited这些JDK内置的用来放在另一个注解上的注解,Javadoc说它们叫做元注解meta-annotation。JDK的这几个元注解有很多文章讲解,我就不讲了,这一篇专讲元注解。

探索

我就好奇了,依赖注入框架所用的元注解是怎么实现的?大家有想过吗?比如说,框架怎么知道哪些注解被标了@Qualifier元注解?第一反应是Java内置了这方面的支持,因为单元测试框架的@Test等注解也有元注解功能,这么常用的功能或许是Java原生支持的?

因此我就做了试验,写两个自定义注解,一个叫@Virtual元注解,一个叫@Real注解,把@Virtual放在@Real上,把@Real放到一个User类上,看看编译结果,然后用反射从这个类上取@Virtual,看@Real能不能自动引导到@Virtual上。示例代码如下:

@Retention(RetentionPolicy.RUNTIME)
public @interface Virtual {
}

@Virtual
@Retention(RetentionPolicy.RUNTIME)
public @interface Real {
}

@Real
public class User {
}

编译后用IDE查看class文件,发现@Virtual元注解仍然只标在@Real上,User类上只标有@Real注解,可证明编译器没有为元注解做什么工作。然后反射的结果也是不能从User类拿到@Virtual,可证明JVM runtime也没有为元注解做什么工作。因此@Qualifier的元注解特性极有可能是相关框架自行实现的。

要怎么实现呢?我们可以自己动脑筋想一想。考虑到,Spring框架扫描所有的class文件(之所以要扫描class文件而非class对象,是因为Java不提供遍历所有class对象的功能,使框架不得不重复实现对class文件的解析工作),将其中有相应注解的class转化为BeanDefinition注册到BeanFactory。那么@Qualifier也可以类似地处理,对于扫描到的class,如果它具有@Qualifer注解,并且自身也是注解(实现了java.lang.Annotation interface),就作为一个自定义注解注册到框架里(比如说,QualifierAnnotationRegistry?),如此一来框架就认识所有的包含@Qualifier元注解的自定义注解了,之后要使用就顺理成章了。

发现

那么Spring实际上是怎么实现的呢?我们可以查源码。到GitHub上找到spring-framework这项目,搜索代码关键词Qualifer或javax.inject.Qualifier,查到90多个Java文件,再在页面中高亮关键词”main”以过滤掉单元测试,凭经验翻阅,在前3页就能找到实现代码了:


sorra
841 声望78 粉丝