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

我记得 ssh 时代，xml 可以说是多到令人发指，Java EE 自己的 servlet 要使用 xml，各种框架也需要使用 xml。

那个时候很流行一个概念，叫低侵入性，Spring 就号称零侵入。也就是说，你可以完全不用修改你的代码，代码里没有任何 Spring 的东西，然后在 xml 里面配置，如果以后不用 Spring 了，完全可以换掉而不必修改源码。现实是，这很难实现，Spring 移除了，程序就不能跑了，找个框架来替换 Spring 几乎不可能，就算可以，又要配置一堆 xml，不同的框架 xml 配置肯定不通用，工作量高到让人绝望。只要是使用框架，侵入是无法避免的，现在 Spring 还是使用注解比较多，虽然官网文档里仍然会给 xml 配置代码，但是用的人很少了。xml 来实现低侵入性，徒增工作量。

那个时候还流行一个说法，叫不修改代码只修改配置，就是不要硬编码。假如你的程序需要一点点改动，那么你可以修改 xml 配置文件，不需要修改 Java 代码，就可以重启使用新的更改。这样做有什么好处呢？如果修改 Java 你要重新编译打包，打包完再上传服务器，直接在服务器上修改 xml 就方便多了。直接通过配置文件改变程序逻辑，比如通过 xml 配置修改 struts 的请求路径等信息，还是有一定的危险性的，程序封装好之后，内部的细节尽可能少暴露。如果真需要做各种修改，直接服务器上改程序逻辑，干脆用脚本语言好了。再加上现在流行容器化了，程序都是要发版的，大规模集群要自动化，这种改 xml 配置的就更少了。一般都是通过设置容器的环境变量来做配置， spring、struts 和 hibernate 配置与程序的逻辑有关，属于程序版本中的内容，不应该可以随意调整。

xml 这套东西确实是弯路，没有能经住时间的考验。现在的 Srping 这套注解配置不知道能不能经住考验，也许再过几年 ioc + aop 这套动态增强技术也会成被认为是弯路。