2  开源框架带来的烦恼
    虽然开源的框架、类库越来越丰富，可供选择的替代者越来越多，但Java程序员却感觉自己慢慢陷入到了技术的漩涡之中：因为他们发现只要一段时间不关注开源社区，就有潮水般陌生的技术框架、专业术语、英文缩略词挟裹着一团团亢奋的热浪将自己淹没，让他们觉得随时都有被Java世界抛弃的危险。许多年纪稍大的程序员甚至觉得职位转换，甩掉技术干管理已经时不我待。

选择的困惑
     雨后春笋般涌现的开源框架都声称自己是最好的，有过多次因盲从于技术鼓吹而失望伤心的经历后，现在的开发者都变得成熟理智了，他们不会轻易相信某个框架自身的承诺，不会轻易附和他人的宣传，这确实是件好事。为了作出理智的选择，他们往往要自己亲自摸索以做出评判。

    有时，我们会发现向上司推荐一个框架已经变成一件困难的事情，因为上司会冒出各种各样的问题：如Webwork比Struts好在哪里？Hibernate和iBatis有什么区别？OpenWFE比之jBpm有什么优势等等。所以要确定一个框架时，往往需要将相似的框架都研究一遍，以便有充足的理由让上司相信我们的选择是最优的。

    但是，要将同类的框架都做一次研究并比较优劣并非易事，如开源工作流引擎就有Willow，OpenWFE，jBpm，Werkflow，OSWorkflow等不下30余种的框架，炫耀的声音一个比一个响亮。每种框架都有自己的设计思路和实现方案，况且这种技术预研性的工作，又不可能在项目周期内占用太多的时间，而不深入预研又不可能客观地作出评判，所以往往是熬红的双眼依然带着迷茫的目光。

    此外，用人单位为了减少新员工的培训时间，对求职者往往有明确的框架使用技能和经验的要求。求职者为了能找到一个好工作，不得不逼迫自己学习更多的框架，以便让自己拥有更多的求职机会。
 
搭配的困难
    开源的繁荣虽然给各个领域都造就了许多优秀的框架，如Spring，Struts，Hibernate，Lucene、OSCache等等，但却没有出现一个一站式，统管全局的整合开发框架。开发者在享用大餐之前，事先得充当大橱的角色，将这些盐，油、酱、菜按合理的方式调配好。
   
    虽然，我们一直强调整体大于单个的总和，但是如何将单个“个体”正确的组合成发挥更大效应的“整体”却并非易事。因为这些单独的框架都由不同的团队开发，框架与框架之间存在天然的阻抗，这种框架和框架之间的“代沟”需要额外配置和编码才能弥合。

    每个框架都拥有自己的配置文件，框架的整合经常带来配置的灾难，如将Spring和Struts整合时，不仅Struts本身的配置文件一个不能少，在Spring中还需要每个Action提供配置信息，而且两者需要遵守一定的契约。

    相互搭配的框架和框架之间经常会出现相似的或重复的功能，如何取舍，如何使用往往让开发者们为难。如Spring本身提供了AOP方法返回结果的缓存功能，而Hibernate本身也提供二级缓存，究竟两者都使用呢，还是择一而从？往往中间又会引出很多争论。

    框架整合的问题已经日益突出，我们可以在各开源论坛或社区发现大量有关讨论的主题。目前也出现了一些试图解决的框架整合问题的开源项目，如国外的AppFuse，国内的SpringSide，为框架的整合提供了专业的指导。但是并没有很好的解决现实开发中的实际需要。这些整合框架为了增加通用性，网都撒得太大，导致整合框架本身象一个庞然大物，让人望而生畏，定制性和灵巧性上都存在不足，降低了它们的实用性，所以这些整合性的开源项目往往降格为指导性的实例。

 升级的困扰
    活跃的框架每天都在升级改造，丰富功能。其次由于开源框架在一定程度上存在随意性，往往导致框架在实际使用后，发现大量隐含的Bug，所以有时对某个框架的升级变得不可避免。开源框架比之Sun正规的规范有着更加灵活的升级方式，高低版本不兼容的问题已经成为司空见惯的事情。如著名的Hibernate，其3.0版本和2.0版本的包名都发生了彻底的变化，刚发布的Acegi和低版本也存在很大的差异，无法兼容。

    一个整合性的框架由多个出自于不同团队的框架组成，整合框架在这些组合框架之上高位运行，底层框架的升级变化就造成了组合框架水涨船高的局面，整合框架脆弱的稳定性很容易被打破。
组合框架的升级还直接带来了开发团队学习的压力，为了熟悉框架新功能和改进，在开发工作之余，他们不得不努力压榨自己的业余时间不断地充电学习。总是某个框架新功能学习还未完成，另一个框架的新版本又在一阵欢呼声中闪亮登场，让开发人员发现自己所有的努力只是一场骑牛追马游戏。