Java配置文件格式的总结

Java配置文件的格式大致有三种：

• Java代码
• XML
• 脚本

诸如spring这种配置bean之间依赖关系的情况(实际上是指明java class之间的调用关系)，webwork这种配置Action之间依赖关系的情况(URL与java class之间的对应关系)的情况，即涉及到概览性描述class的情况，是非常适合使用Java语言本身去描述的。同样的情况还有struts- config.xml等等。这些情况是Jacn大展伸手的地方。

涉及到颗粒度很细的class自身内部的信息，则非常适合使用annotation去描述，例如Hibernate的hbm映射文件， Webwork Action的validation.xml文件等等，所幸的是，Hibernate和Webwork都提供了相应的annotation功能。

还有一种情况是不依赖与任何class的流程性，规则性描述，例如工作流定义，规则引擎的规则定义，ant的编译文件等等，这些东西非常适合与使用 纯脚本去描述，因为他们本身带有比较强的程序逻辑性，却又抽象级别比较高，我认为非常适合使用groovy这样的脚本语言去描述(当然类似的脚本还有很多 例如beanshell等等)

最后，我认为XML适合场合在于异构系统的整合，以及松散藕合的分布式调用上面，即web services适用的场合(XMLHTTP实际上也是某种程度上面的web services)，目前比较热门的商业词汇SOA描述的应用场景正是XML大显身手的地方。

综上所述，我认为XML在Java世界这么多年来，被严重误用了。看看Python配置文件多喜欢用py，Ruby配置文件多喜欢用yaml，我们要反思一下，并不是不能够用Java写配置文件的。

当然考虑到编译性语言的编译需要和语法的严谨性限制上，并不是什么配置都适合使用Java的，然而spring和webwork配置文件这种描述class之间关系的配置无疑不应该使用XML，也不应该使用脚本，而应该采用Java。

---

我现在越来越反感用XML来作为Java web项目的配置文件了，尤其是Spring的XML配置文件和Webwork的XML配置文件。项目一旦变得比较大的时候，想要重构，是非常困难的。所 以我认为，必须消除XML配置文件，而且必须让配置信息可以有重构支持，所以这种配置信息必须以Java代码的方式来编写，也就是说应该用 annotation去写，而不是XML。所以Hibernate的映射文件非常适合使用annotation，而spring和webwork这种全局 性的配置文件，用annotation则太分散了，用Jacn就很不错，考虑给Jacn增加webwork支持。

---

我觉得配置烦琐到不可怕，真正可怕的是没有编译器检查和IDE的重构支持。我现在持有这样一种观点，配置信息用脚本还是XML没有本质上的差别(虽 然脚本的可读性更好)，对于一种编译语言来说，就应该充分利用编译检查这个优点，否则的话，就干脆全部使用脚本语言编程得了。特别是当我看到RoR使用 ruby 来写yaml配置，就更加确定这一点，那就是Java项目的配置信息就应该写在Java代码里面，这样才能充分发挥Java的优势，用脚本还是XML配置 的路子都不对。

jacn的源代码味道很不好，不过实现原理非常简单，就是用Java去编写配置，然后程序运行的时候读取class文件的bytecode，转换为 框架XML配置需要的XML DOM送给框架。实现的要点就是能够通过bytecode读取配置信息，可以把这一功能做成一个基础平台，然后各种框架需要的DOM信息分别写插件实现， 其实就是另外一种形式的XDoclet，只不过XDoclet读取的是Java源代码中间的注释信息，而Jacn读取的是Java源代码编译的class bytecode的信息而已，但是显然Jacn这种方式的好处就是编译器可以进行检查，IDE也可以提供重构支持，另外用Java代码写配置，很容易实现 一些XML配置很难配置好的功能，例如AOP，事务支持什么的，用Jacn就是一行代码搞定，很直观。

目前对我来说，就是急需给Jacn增加webwork配置文件的功能支持，我准备在有空闲时间的时候做一点这方面的工作，因为一般项目的action数量是很多的，重构Action的时候，对xwork.xml同步修改能力极差，这个缺陷严重影响了对项目的重构质量。

虽然spring和webwork都开始提供annotation支持，但是这种全局性的配置文件不同于Hibernate，他们需要提供一种概览性质的东西，这个时候Jacn比annotation要合适。最后我觉得Jacn这种在Java代码里面写配置的创意很棒