你可能还记得 AMC Gremlin——它强有力地竞争着“史上最丑汽车”的称号。Gremlin 是上世纪 70 年代生产的，但现在仍能看到一些，就像我去年在旧金山拍下的这辆一样。

如今的企业级 Java 体验让我想起了这个美国汽车工业的遗产。Gremlin 是对石油危机的无奈回应。AMC 需要一款“紧凑型”汽车，于是他们拿来了现有最小的汽车，然后将其砍掉一半。最终的结果出人意料地卖得很好，但也明显暴露出其前部和后部是由不同团队匆忙拼凑而成的迹象。毋庸置疑，最终在小型车转型中胜出的是日本和欧洲制造商。

Java 中的 Gremlins

如今，企业级 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 领域的老牌供应商也对造成最初诸多生产力问题的复杂性负有责任，因此它们不太可能是解决这些问题的最佳人选。此外，尤其是在行业最近整合之后，它们都是庞大的公司。庞大的公司通常不追求简洁性——而且，这样做往往不符合它们的利益。

展望未来

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 专注于这个目标，有能力实现它，而社区既支持我们的努力，也将从中受益匪浅。