java xml 框架_java的那些框架曾经疯狂地使用xml，说是不用硬编码，但现在怎么感觉又“去xml化”回归硬编码了？...

win下面有个api叫做CreateWindow，要创建窗口应用就要调用这个api，它有十多个参数需要传递……包括窗口位置，窗口标题，窗口成分(最小化按钮和最大化按钮有无)等。

参数多了会有什么问题呢？首当其冲就是不方便记忆，其次就是代码会写的很长，最后是令人反思真的要这么多参数吗？我不想处理那么多我想大部分给个默认值行不行？

参数过多这个问题，很多人动手解决了。大体上的解决方案都是写一套库封装窗口创建的过程，使用者不需要自己调用这个函数，这一套参数都有默认值，如果需要修改某个值，调用另一个setXXX来修改。这样就可以避免了参数过多的问题了。

然而新的问题来了，这种库选择的默认值不够令一些使用者满意，每次都在代码最前面重新配置一次默认值，又显得非常不优雅，于是这种库的作者增加了一个功能：设定默认值。但是总不能和CreateWindow再撞车回去吧？所以聪明的库作者想到一个新方法：把默认值配置到程序外面来！所以配置文件出现了，它们大部分时候后缀是ini。

后来java各大web框架的xml文件策略只不过是继承了这样的优良传统：已封装好的库代码，为了使用上的方便，通过一套封装者规定的协议(这里是xml)去配置库代码的缺省参数。这里跟耦合程度其实没多少关系，就是我使用别人的库而已。

那为何后来注解把这一套方案替换了？因为注解把问题的核心解决了呀！我使用你的框架，需要配置你的缺省参数，配置的位置就在我的代码中，这才是最方便的用法，另起一个xml文件，xml得解析吧，xml怎么列得有详细文档吧，文件命名得规范吧，得手动校对是否符合字段定义吧？难道在我自己的代码中来一长串setXXX来配置参数？简直是代码污染好不好？现在一个注解，达到了同样的目的，还把这些问题都解决了。显然，这是一种技术上的进步，值得替换掉旧的方案。

至于xml是不是弯路？那当然不能这么说，毕竟注解是后来才加上的功能。如果没有注解，配置文件依然是众多方案中最让人认可的一个。