二、 注释——真的能简化吗？
笔者问过一些做Java开发的朋友关于对注释的了解情况。很多都说，在实际的项目当中，依然在使用Java1.4及EJB2.0，因为还没有到不得不使用注释的时候。当然，在平时的学习当中，可能会有涉及到注释。
注释是代码文件中的伪代码，而代码之外的一些配置文件，如XML及*.properties，感觉更加容易从编译过的部署类里具体化。这两者可能各有优点，那我们普通的开发人员依据什么来决定，到底是把元数据写在源文件代码里，还是写在单独的配置文件中呢？
有一点可以肯定，其它能像Java这样提供注释功能的语言并不多。引入注释的目的无非就是想把一些需要单独或是额外解决的问题，引用于源文件中一并解决，但这并不一定能起到药到病除的效果。
让我们看看使用注释在类文件中写入配置信息的情况：这意味着需要重新编译才能反映配置信息的改变，配置不能在Java程序外面单独的加以操作与配置。同时，对于使用那些支持注释及非注释两种类型的框架，无疑会使项目的配置更加混乱，增加维护难度。
如果一个软件在试运行或是真正使用时，碰到用户需求变化或者原来功能不能正常运行，如果一些基本的配置信息都写进Java源文件中，一般的作法是：需求反馈到该程序设计程序员，程序员修改代码，再进行测试，可能测试不通过，影响其他功能了，再测试，折腾很长时间，最后编译打包，交付客户。
如果使用XML和Java分离方式：水平较低的维修人员赶到现场，修改一下配置XML，无须编译Java代码，测试，马上解决问题。很明显哪个更快呢?
所以，开发软件不能只顾自己开发时方便，还要考虑到运行维护时是否方便，软件不像冰箱，制作好交给用户，很坚固，很稳定，用户也不会提出什么修改意见，当然海尔的定制化冰箱有这个意思，但是这种水平不是一般厂商水平能够做出来的。
当然，笔者并不反对或是拒绝任何可以提高软件开发效率及节约时间的方法或技术，但这有个前提，就是这种技术或方法的成本或是代价。有些人会说，将一些部署逻辑或是信息嵌入在代码中，这样可以减少文件的间接访问，增加代码的集中度。但是，在一个满是注释的源文件中，去提取特定的配置注释，这无疑会增加代码的分析时间。此外，笔者们又如何给那些没有源文件的类文件进行注释呢？最后，注释又为何要整一套自己的新语法？它本来就像Java语法，那有必要另起炉灶，再整一套自己的语法吗？
当然，笔者也承认，注释有它肯定的一面，并且可以肯定，其初衷是好的。但笔者认为，在EJB3.0规范中，其注释的规范有些太过极端了。因为很明显，这已经违背了软件的简易性原则，增加了开发的复杂性，使代码的可维护性降低了。
