针对Spring的驳斥。如果你看看Amplicate（一家评论网站），你可能会对Spring有不好的印象，但它可能只是一些有偏见的用户。一些评论者作出的一些评论有一些优点，但许多所谓的缺陷能够变成优点，而一些则是有必要进行权衡。让我们看看一些最常见的投诉，其中一些问题特性实际上可以加强Spring框架，而其他的可以很容易地处理。

　　XML是魔鬼

　　有许多人抱怨创建一个Spring应用程序需要多少XML。开发者抱怨这个可能没有意识到，Spring已经在多年前就提供了一个XML和注释之间的选择。事实上，现在在这些格式和类似于Google Guice的一个基于Java的格式，或其他基于代码的注入API之间存在一个选择。

　　太多JAR包

　　另一个经常使用的参数是，Java EE提供你需要的，立即可用的一切。最近，费城新兴技术的Web框架的枪战，在2011年的春天展开，一个Java EE小组成员大声抱怨，团队在Spring中不得不引进大量的JAR包创建他们的项目。最好的答案是由SpringSource的Jeremy Grelle提出的，他说了一些具有影响力的话，“这不就是你所想得到的全部吗？”

　　企业软件不应受制于什么附带产品。与其他技术集成是一个关键的活动，并且Java开发人员都非常具有创新精神。开发人员常常需要去框架外面选择一个新的API，如最新的最热门的JSON解析器、Web框架、视图技术等等，以满足自定义的需要。在这种普遍情况下，总是会有一个需求，让你去找一些外部API并集成它。

　　话说Spring不应该被使用，因为它没有“被认可的、内置的”API，使用外面的API是旧思想。我们不应该把自己逼迫到一个盒子中而进入一个死角。我们应该能够选择库,它提供给我们最好的组合功能，兼容许可，一个丰富的开发人员社区和支持。简而言之，Spring和所有其他企业API——无论是来自Java EE或任何开源厂商，如Eclipse或Apache——都应该提供给开发人员。

　　Spring的代码不是Java EE标准代码

　　当然，你可以编写完全便携式Java EE代码并在任何容器运行它。你也可以在必要时选择Spring API，但你会受到限制，只能运行在Spring容器中。然而，随着Spring在企业中的流行,挑选一个Spring API来使用，一般来说不会是一个糟糕的选择。

　　如果可能的话，Spring团队已经编写了程序让自身跳出这个方程。例如，在Hibernate 能支持sessionFactory之前。getCurrentSession API、SpringSource推荐使用HibernateSupportDAO和HibernateTemplate API,它会自动建立和拆除Hibernate连接。现在,在Spring中，Hibernate支持ThreadLocal连接，并且能够在幕后集成到事务支持，开发人员不必被迫在Hibernate DAO / Repository类中使用Spring注释。

　　逆向也正确。

　　开发人员可以编写代码，它将接受来自一个JMS容器的访问而不使用任何JMS代码。Spring支持发送消息到一个简单的Java对象，甚至使用Spring转换器框架，将传入消息转换为有效负载到Java bean。这个提升可以促进编写业务级别的抽象，允许Spring将企业消息传递API转换成一般的商务呼叫，因此开发人员就不会浪费时间处理一些杂乱消息，只需要处理发送和接收异步消息。

　　最后，Spring支持使用标准的Java EE注释,如@PostConstruct,@PreDestroy,@ resource等等。如果你需要一个Java EE API，请务必使用这种方法。只有把基础设施与API打包，您才将获得好处。

　　总结

　　我觉得Java EE从它开始作为Java兄弟到CORBA和EJB 0.9/1.0，取得了长足进步。从90年代以来，Java语言已经有了大幅度的提高，并且自从甲骨文购买了Sun，加速了它的创新。这是一件好事。然而，另一个好事不是试图扼杀非常生态系统,相反Java EE已经帮助了其成长。

　　如果Java EE不与Spring竞争,它能改进这么多吗？如果Java EE没有Hibernate作为在数据库API领域的一个竞争者，它能创造JPA吗?如果Java没有Ruby、Groovy、Clojure等竞争对手,它会考虑封装和资源清理代码吗?

　　总之，创新来自于很多地方并刺激其他人的行动。我们可能会发现SpringSource促使Java EE的改变,这是好事。不好的是建议我们不需要“第三方”API了，因为Java EE已经很成熟。