您可能还记得AMC Gremlin——有史以来最丑汽车的有力竞争者。Gremlin 生产于 70 年代，但现在仍然有一些，比如这个，我去年在旧金山拍摄的。

如今的企业级 Java 体验让我想起了这件美国汽车遗产。Gremlin 是对石油危机的一种绝望的回应。美国汽车公司需要一款“紧凑型”汽车，所以他们拿出了他们最小的汽车并将其一分为二。最终的结果出人意料地畅销，但它也明显地表明，它的前后部分是由不同的团队生产的，并且仓促拼凑在一起的。不用说，在转向小型汽车的过程中，日本和欧洲的制造商取得了胜利。

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 部分通过牺牲处理复杂场景的能力（例如使用遗留数据库）来提高生产力。微软的成功是通过垄断实现的。当一家公司控制所有部分时，更容易实现集成结果。

幸运的是，开源提供了实现相同结果的机会，但以更开放的方式。虽然没有一个单独的开源项目可以解决整个应用程序生命周期，但供应商可以构建一个高度依赖开源的集成体验，从而最大程度地减少供应商锁定。建立在开源基础之上，还可以让供应商在每个领域选择市场领先的解决方案，而不是从其内部零件库（类似于美国汽车公司）中拼凑出一个产品。

不仅仅是开源

但是，仅开源并不是解决方案。开源项目通常擅长解决软件堆栈或生命周期中的特定问题；它们在集成所有部分方面远不如擅长（也缺乏兴趣）。一个解决大局并在整个应用程序生命周期中起作用的现代解决方案，必然会依赖于开源，但需要供应商的支持和支持。

令人惊讶的是，在 Java 领域，似乎没有一家供应商能够应对这一挑战，而且很少有供应商尝试过。尽管控制着 Java 规范，但 Sun 从未成为一家强大的企业级 Java 供应商，而且似乎从未完全理解 Java 中的生产力问题。（此外，生产力问题通常由产品而不是规范来解决。直到最近，而且可以说为时已晚，Sun 才开始在 Java 领域意识到这一点。）IBM 确实拥有涵盖整个生命周期的解决方案，但在 IBM 的案例中，拥有统一的愿景并不能弥补大多数组成部分的糟糕生产力特性。任何以 Rational Application Developer 为起点并以 WebSphere 为核心的软件生命周期解决方案都不太可能提供现代的生产力体验，或使 Java 能够与竞争平台竞争。微软，尽管存在各种缺陷，但比任何传统的企业级 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 来帮助加快使用 Spring 的企业级 Java 开发。

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

构建/运行/管理生命周期是我们看待世界的方式的核心。您将在未来几周和几个月内看到有关产品和构建计划的重要公告，以加强我们在整个生命周期中的故事。您将看到我们扩展我们的技术以追求它。

我相信，SpringSource 将通过解决这些问题而成为主要的中间件供应商。但是，真正的赢家是您。企业级 Java 可以（也需要）更高效。SpringSource 专注于此目标，拥有交付能力，并且社区既是我们的基础，也将会从我们的努力中获益匪浅。