你可能还记得AMC Gremlin——它是最丑陋汽车的有力竞争者。Gremlin是在70年代生产的，但仍然有一些，就像我去年在旧金山拍到的这辆。

如今的企业 Java 体验让我想起了美国汽车工业的这段遗产。Gremlin 是对石油危机的绝望回应。AMC 需要一款“紧凑型”汽车，于是他们拿出了最小的车型，然后将其一分为二。最终的产品销量出奇地好，但却暴露了其前后部分由不同团队生产并仓促拼凑而成的明显迹象。毋庸置疑，在转向小型汽车的潮流中获胜的是日本和欧洲制造商。

Java 中的 Gremlin

如今，企业 Java 感觉很像 Gremlin，这对生产力来说是一个主要问题。无论是从技术栈的顶层到底层，还是在整个应用程序生命周期中，各个部分都来自不同的来源并被拼凑在一起。虽然大部分组件都很好，但有些对于典型场景来说却过于臃肿。可悲的是，我们已经习惯了这种状态，并对由此带来的生产力损失习以为常。例如，通常我们会使用开源构建工具（Ant 或 Maven）来构建应用程序；使用来自不同项目或供应商的 IDE，手动集成大量插件；围绕开源框架构建应用程序；但最终却部署到另一个供应商的应用程序服务器上——而且集成通常相对表面化。

其中一些部分几乎是理所当然的：例如 Spring 和 Hibernate、基于 Eclipse 的工具套件，以及（越来越多地）Apache Tomcat。但整个体系的运行既依赖于开发人员为每个项目做出大量选择，也依赖于大量的内部粘合剂和支持——后者是我们忽略或屈从于成本后果的另一个领域。

不必如此

其他平台上的经验表明了整合思维的好处。Ruby on Rails 生产力的大部分成就归功于它提供了集成体验；开发者会被做出选择，例如，构建工具与应用程序框架携手并进。Rails 的前提是应用程序框架建立编程模型，这有助于为连贯的理念提供基础。

微软也提供了一个很好的例子。微软将从 Visual Studio 到 SQL Server（甚至到 Azure 云）的一切都视为单一愿景的一部分，并且，虽然并非所有组成部分都是理想的，但其结果比企业 Java 提供的集成体验要好得多。

当然，这两个例子都不是完美的。Ruby on Rails 通过牺牲处理复杂场景（例如处理遗留数据库）的能力来获得生产力。微软的成功是通过垄断实现的。当一家公司控制所有部分时，实现集成结果会更容易。

幸运的是，开源提供了以更加开放的方式实现相同结果的机会。虽然没有单个开源项目能够解决整个应用程序生命周期的问题，但供应商可以通过大量利用开源来构建集成体验，从而最大限度地减少供应商锁定。基于开源还可以让供应商在每个领域选择市场领先的解决方案，而不是像 AMC 那样从内部零件库中拼凑产品。

不仅仅是开源

然而，开源本身并不是解决方案。开源项目在解决软件栈或生命周期中的特定问题方面通常很出色；它们在集成所有组件方面则差得多（并且兴趣也小）。一个解决大局、贯穿整个应用程序生命周期的现代解决方案，将不可避免地依赖于开源，但需要供应商的支持和帮助。

令人惊讶的是，在 Java 领域，似乎没有一家供应商能够应对这一挑战，甚至很少有人尝试过。尽管 Sun 控制着 Java 规范，但它从未成为一个强大的企业 Java 供应商，也似乎从未完全理解 Java 的生产力问题。（此外，生产力问题通常是由产品而不是规范解决的。直到最近，而且可以说是太晚了，Sun 才开始在 Java 领域认识到这一点。）IBM 确实有涵盖整个生命周期的解决方案，但在 IBM 的案例中，清晰的愿景并不能弥补大多数组成部分的低生产力特性。任何以 Rational Application Developer 开头、以 WebSphere 为核心的软件生命周期解决方案，都不太可能提供现代的生产力体验，或者使 Java 与竞争平台竞争。

企业 Java 的现有供应商也应为造成许多生产力问题的复杂性负责，因此它们不太可能是解决这些问题的最佳人选。此外，尤其是在行业最近的整合之后，它们都是大型公司。大公司通常不会追求简单——而且，它们通常不以获得简单为目标。

展望未来

Java 需要一个新的旗手，而这个旗手将不是任何一家现有公司。SpringSource 致力于改变企业 Java 的体验——我们已经做好了提供这一切的准备。

Spring 和 SpringSource 一直专注于消除企业 Java 的复杂性。“消除企业 Java 复杂性”现在是我们的公司标语。为此，我们已经努力工作了 6 年多。虽然 Spring 最初是通过创新来最小化企业 Java API 的复杂性，但它早已扩展到解决更广泛的挑战——例如安全、批处理、集成和 Web 服务——同时 SpringSource 作为一家公司，其业务范围也比 Spring 更广。凭借 Spring、Grails、Spring Dynamic Modules 和 SpringSource dm Server 以及 OSGi 的简化，SpringSource 长期以来一直引领着企业 Java 生产力的发展方向。

消除企业 Java 的复杂性意味着要考虑应用程序生命周期的每一个阶段。它不仅仅是一个服务器或应用程序框架，无论它们有多好。很难想象任何现代的、完全集成的解决方案不大量依赖 Spring，但 Spring 只是其中的一部分。

构建、运行、管理

整体提升生产力涉及考虑生命周期的三个关键阶段：应用程序被开发时的构建阶段，应用程序被部署到服务器时的运行阶段，以及应用程序在生产环境中被维护和操作的管理阶段。

这一重点解释了为什么我们现在是 Grails 的幕后公司——JVM 上最高产的技术；以及为什么我们构建了 SpringSource Tool Suite 来帮助加速企业 Java 与 Spring 的开发。

这解释了为什么我们已经进入了其他领域，例如应用程序服务器领域——在行业领先的应用程序服务器（Tomcat）中占据领先地位，并构建了下一代模块化应用程序服务器 SpringSource dm Server。这解释了为什么 SpringSource tc Server 和 SpringSource AMS （Application Management Suite）为部署到数据中心的应用程序提供了强大的管理功能。

构建/运行/管理生命周期是我们看待世界的中心。在接下来的几周和几个月里，您将看到关于产品和构建计划的重大公告，以加强我们在整个生命周期中的战略。您将看到我们扩展我们的技术以追求这一目标。

我坚信，SpringSource 将通过解决这些问题成为一家主要的中间件供应商。然而，真正的赢家是您。企业 Java 可以（也需要）变得更具生产力。SpringSource 专注于这一目标，有能力实现，而社区既支持也受益于我们的努力。