其实Annotation这样就美了...

是的，annotation的出现减少了繁杂的配置文件，将那些原本可能是runtimeException的东西扼杀在了编译期。
不过最近在考虑一个小项目的时候发现想要用它来完全代替传统的配置文件还很困难。
首先，它无疑使得代码变得难看，这一点不用多说了；
其次，它不支持多份配置：
因为annotation怎么说也是直接写在代码里的，写在类的定义里的。也就是说一个类也就只能对应一套annotation。那么遇到这种情况：我想初始化同一个类的很多个对象作为prototype或者说单例的共享对象，我要求这些对象虽然是同种类型、拥有同样的行为，但要包含不同的数据。我在项目中遇到这样配置要求的话目前的annotation根本无法满足，还得使用传统的“配置”。

上面说的只是“对象”层次的“多份配置”，或许有人认为这本来就不该是annotation的工作，所以不怎么有说服力。但是我仍然相信存在真正的“类”层次的“多份配置”的需求的：比如你想对同一个类做出同种类型但不同实例的代理呢？显然靠annotation是不行的。

那么，我有一个想法：为什么不把annotation“抽出来”呢？也就是把annotation从Java源码里面搬到一个专门的文件里。我们也许会觉得“这跟‘配置文件’有什么不同？”，但我觉得如果这成为Java的规范的话，它完全可以提供编译器的支持，把这些独立出来的文件当成那些java类文件的延伸，编译的时候还是作为一个整体处理...这样的话它既有了annotation的优势，又能像传统配置文件一样强大，就更美了。

另外，我也不是故意要将annotation用传统的配置文件的标准来衡量。其实依现在的annotation来看，它的目标并不是作为传统配置文件的替代品。它只是想让大家把那些“不至于”或者说根本不应该放在配置文件里的东西放到它里面来，可以缓解滥用配置文件的情况。但该“配置”的地方还是要配置，传统配置文件的作用在很多情况下仍然无可替代。

当然，我想如果annotation真的迈出这一步，那么它就真的能很大程度上替代传统配置文件了。