Java 是否真的即将被取代？ --COBOL 式死亡

本文为转载 ：

对于最近有关 Java™ 即将退出历史舞台的传言，您可能想知道在这个时候放弃使用 Java 平台并转而使用更新的技术是否时机成熟？在作出您的判断之前，请先回顾并查看一下 Java 生态系统以及它的竞争者，看看这些传闻是否站得住脚。换而言之，了解整个 Java 世界目前的现状，并客观公正地评判这个平台。

在学生时代，我们可能会想起 Thomas Malthus 所做的预言，他认为人类赖以生存并继而形成人类文明的农业体系，可能无法再承受人口数量的不断攀升，另一方面，这种情况将不可避免地造成严重的后果，通常 会引起巨大的灾难或其他自然灾害。他这样写道：若对人口数量不加限制，将呈几何级数增长。而人们赖以生存的物质则以代数级数增长。与后者相比较，如果稍微 了解一下这些数字，就会意识到人口增长是多么惊人。这意味着，针对生存物质的匮乏，需要对人口增长进行严格而持久的控制。物质匮乏终究会发生在某些地方， 并且必定会严重影响到大部分人类。

Thomas Malthus 在 1798 年发表了 “人口论”。从那时开始，我们一直在等待着验证有关人口增长的 “Malthusian 检验”。

编程人员，特别是使用 Java 平台和语言的人员，可能已经注意到，随着使用难度不断增加，人们的种种预测和统计暗示着他们所选择的平台即将没落。而大量候补接任者跃跃欲试：人们提名 .NET、Ruby 甚至是 Python 作为 “下一代重要技术”。

这两种 “Malthusian 学说” 之间存在着惊人的相似之处。

Malthus 认为，由于食物对人类的生存非常重要，而地球的产出有限，并且繁殖所需的生物体系是不会改变的，我们终将达到一个极限，那时地球将无法承受人口负担。换句 话说，如果继续以现在这样的方式生存，将注定灭亡的结局。那么在 1798，很难推翻 Malthus 的学说。

同样，在过去十八个月中，Java 社区出现了一种新趋势：即预测 Java 平台的消亡日期。从一些低级的新闻杂志将其称为 90 年代的技术，到夸大其辞的技术演讲者宣传它的现状，再到各种书籍宣称我们正在 “超越” Java 时代，不难发现一点：通过合理的暗示、代码演示、逻辑或统计性说明，Java 正在走向没落。

Malthus 忽略的是那个时候正兴起的工业革命。在 Malthus 一生中，他能够目睹到人类农业生产力的巨大飞跃，这要感谢蒸汽机和轧棉机这些发明。这些发明为他的学说提供了必然的“缺少的一环（missing link）”，它们使粮食产量成倍增长，从而使农业系统能够拟制由“两性激情”制造的沉重的人口负担。随后，人口控制方面的技术创新对降低人口增长起到了 相同的作用，减轻了人口负担，从而造成了很多西方国家出现人口负 增长，因此情况与 Malthus 的相当合理的逻辑完全相悖。而所有这一切在 Malthus 撰写其论文时是无法预见的，使人类能够超过他所预测的农业系统的承受极限而继续存活，并且避免了由此而来的一系列灾难。

而技术批评家所忽略的则是 Java 虚拟机的替代语言的兴起引发了巨大的变化。不过不要轻易相信我的一家之言，让我们逐一查看支持这种说法的论证，看看它们是否站得住脚。

Malthusian 式的 Java 预测

一些人仅仅引用了一些统计性描述，说明 Java 不再是程序员中最重视的语言，就简单的判定 Java 已经在走下坡路。其他人指出 Java 缺乏其替代环境所提供的某些特殊特性，这些特性被标榜为用户及其应用程序的 “需求”。还有一些人发表（毫无事实依据）诸如 “大企业不会再使用 Java” 等言论，从而明确地暗示，如果大企业不使用 Java，那必定是因为这种技术不值得使用。

Java 语言，从更大的程度来讲，Java 平台及其生态系统，很早以前就超过了 Simon Peyton-Jones 所谓的 “生存阈值（The Threshold of Immortality）”，就像 C++、C、COBOL 和其他语言所经历的一样。这些工具几乎可以永远存在下去，这是因为它们将继续提供有用的功能，或者是因为重写代码的尝试可能要比继续按原样使用和维护系统 付出更多的代价（有关特定语言或系统究竟属于这两个原因的哪一种，存在很多的争议，而这对于本文的目的则无关紧要）。

另一个论据让所有聪明人都放弃 Java 而转向平台 X 或语言 Y。在 2005 年的一篇 BusinessWeek 文章 “Java? It's So Nineties”中，引用了很久以前就倒闭的应用服务器公司 NetDynamics 的前 CTO Peter Yared 的话，“Java 像恐龙一样古老”。可是，还未来得及搞清楚利益冲突和推理逻辑，这篇文章就写到 Yared 所有的公司正在尝试在 LAMP（Linux®/Apache/MySQL/P-language）栈之上重新创建应用服务器体验。

（这样做可能有些无礼，但我还是要指出 Ruby 的构想实际上早于 Java，同样还包括 Perl 和 Python，更不要说 Linux、Apache 和 MySQL……这里我就不便再多做解释了）。

引用我喜欢的一部电影，“生活是痛苦的，殿下。持不同观点的人一定有所企图”。或者，为了更恰当地解释这个主题，可以这样说：“过渡到一个新的平台是痛苦 的，CTO 先生。持不同观点的人一定有所企图”。也许并不令人惊讶，对于一些已经重新定位到其他技术领域的 Java 专家来说，情况确实如此。

来看看另一个论据，它说 “Java 的顶级语言的位置已经不保，因此它的衰退必定非常悲惨，因此最好避开这场灾难”。这种论据所依据的是一个最基本的前提，即如果 Java 不再是世界上最畅销的技术，则不值得再提供该语言的支持。而这种说法若经过逻辑推理，则根本毫无道理。

统计信息很久以来一直被认为是不可靠的（如果使用不当的话），正如 Benjamin Disraeli 的巧妙解释，他说：“世界上有三种谎言：谎言，诅咒和统计”。统计信息可以用来论证最靠不住脚的论据，只需要根据论据仔细挑选所需的统计信息。注意 BusinessWeek 一文中使用的引用：“调查……显示 Java 的使用逐渐没落，而 LAMP 和 Microsoft® 的 .NET 技术势头强劲”。喔，听上去情况不妙。但是，请继续读下去，“根据 Evans 的秋季调查显示，在北美使用 Java 作为其首选编程语言的开发人员的比例已下降到 47.9%，而 2002 年秋为 51.4%”。因此，在过去六年中，在使用 Java 作为其首选 编程语言的开发人员中，使用率下降了 3.5 个百分点。

请注意，这里使用了 “首选” 编程语言一词，这意味着开发人员自己需要区别什么是他们的 “首选” 语言。考虑到大量的 XML 配置，使用 Spring/Hibernate/JSP Java 栈的开发人员可能可以很好地判断出 Java 不再是他们的首选语言。

注意过去六年中 Java 平台之上兴起的动态语言（Jython、JRuby、Groovy 甚至是 JavaFX），根据我和我的同事（“No Fluff Just Stuff” 的演讲者）在 NFJS 活动的非正式投票中获得的应用数字，这些动态语言可以很轻松地解释这三个百分点的下降。

考虑同样摘取自同一篇文章的引用：“在另一份调查中，今天秋季，PHP 在北美的采用已经上升到 36.1%，而 2002 年同期为 26%。其增长速率几乎和欧洲和亚洲一样快”。考虑到这是一个不同的调查系列，它只是为了显示 PHP 的增长，而不是 Java 市场的萎缩。祝贺 PHP，但是任何研究过企业环境的开发人员都可以证明，生产软件部署并不像这篇文章的作者力图暗示的那样是一个零和（zero-sum）游戏。大型 IT 环境通常由种类繁多的工具、平台、语言和产品组成。事实上，我们几乎可以在这里实现 整合，特别是那些大型机组件。

谈到主机，事实上，COBOL 在几十年前就不再是最重要的语言了，但是，它现在仍然继续用于现金支付、转移存款、支付信用卡等业务并运行主要的金融网络，尽管很多行业权威早已经宣布了 它的 “死亡”。对于本应在坟墓里腐烂的技术，这实在是不错；这使我想起 Mark Twain，当他看到家乡报纸上他的讣告时说：“先生们，关于我死亡的报道被严重夸大了。”

然而，撇开统计数字的问题不谈，第二个问题更严重：为什么仅仅因为所选的工具不是最好的就弃而不用？Java 占据软件开发的首要地位近十年，仅仅由于它 “下降” 到第二位，游戏就结束了？甚至认为仅仅因为人们的惰性就会阻止 Java 重新恢复首要语言的位置，事实是，10 个程序员里面有 4 个会继续使用这种语言，这将保证 Java 在未来几十年里仍然保持活跃的生命力。更荒谬的说法是，Java 的增长将面临急刹车，并且再也不会出现 Java 部署，然而，Java 目前在整个行业内得到了广泛的部署，这可以保证 Java 继续出现相当长的时间。

尽管 COBOL 被宣布已经死亡，但是要求使用它的人每年达到 6 至 7 位数。

检查证据

然而指出一个论点的缺点并不能证明另一个观点，对于本文也是一样的。相反地，我们应该用批评的眼光看待 Java 语言和平台，而其强项和劣势经受住了严格的分析。Java 之所以长寿在于它能满足未来十年的需求，而不是由任何作者或批评家来决定它的生死。

最后，我们考虑一下构成 Java 平台的那些组件：

* Java 编程语言。坦率地讲，这是平台中最能体现其长寿的部分，特别是与一些诸如 C#、Groovy、(j)Ruby 或 Scala 等更 “现代的” 语言比较时。近来涌现出大量关于改善该语言的建议，诸如为该语言添加闭包等极具竞争力的提议，证明了程序员非常渴望 Java 能够具备其他语言的一些特性。然而，Java 5 中最新语言增强功能所带来的联合成功应该成为所有新的重大语言变更的“注意刹车”的提示。某些增强，比如 for 循环或注释，得到（相对）普遍的支持。然而其他一些增强，比如泛型，则受到（相对）普遍的嘲笑和批评。事实是没有任何一种语言功能能得到它本应帮助的开发 人员社区的普遍接受，这个事实告诉我们：为一个已存在十年多的语言添加新的语言特性是很棘手的事情，如果完成，也很可能会导致语言自身的崩溃。在 Java 平台的地图中，这个区域标注着“老水手”的警告：“此处有怪物！”

* 非 Java JVM 编程语言。在 Java 止步不前的地方，其他语言提供改进和增强的解决方法。Groovy 围绕 Java 对象提供了一个动态、客观的脚本解决方案。(j)Ruby 在 JVM 之上提供 Ruby 实现，为 Java 程序员开辟了 Rails 和 ActiveRecordoffers 的世界。Scala 和 Jaskell 给 JVM 引入了函数编程概念，为所出现的并发性问题提供可行的解决方案。诸如此类。由于所有这些语言要么编译成字节码，要么通过 javax.script API 作为解释语言在 JVM 上运行，因此 Java 生态系统的所有财富都是可以利用的— 而这是 Ruby 开发人员无法做出同等声明的一个方面。在 Java 平台的地图中，这个区域被标注为“机遇之国”。

* Java 虚拟机。 幸运的是，Java 语言已经做出了重大修订和根本性的变化，而 JVM 作为 Java 平台的底层基础，变化并不多。近来，在博客世界中，许多人建议使 JVM 对动态语言更友好，这使 Sun 公司的一名工程师（John Rose）提供了 JVM 的修订版，最初称为多语言虚拟机（ Multi-language virtual machine，MLVM）, 现改名为 Da Vinci Machine（因为紧密地包装在代码中）。此处的关键在于被提议的 JVM 更改要避免任何有可能使 Sun 公司在 JVM 优化上的庞大投资作废的事件。那些提出建议的人在设计细节时一直将这一点牢记于心。

* Java Standard Edition 库。 Java Standard Edition 附带了巨大的函数集，数量级比 C++ 标准库更大，甚至许多因素比它前身 Java 1.0 都大，并且这还没有考虑 Enterprise Edition 库（接下来讨论）。表面上，这看起来像 Java 开发人员的自然优势，但仔细考虑就会发现一些细微的问题。对初学者而言，库的庞大意味着许多 Java 开发人员认识不到他们在写一些实际已经存在的代码，这些代码收藏在一个在此之前未知的包中。根据存在时间的不同，库本身有时也会遇到 API 设计时间的烦恼，其中有许多 都源于 90 年代中期，那个时候开发人员设计类和库的方式与 2008 年的设计方法截然不同。一部分开发人员也深受抽象过多之苦，正如创建对象构建者的工厂所例证的一样，这些对象构建者创建的接口实例不一定能实现开发人员感 兴趣的方法。然而，虽然 JSE 库有缺陷，但从整体来说 JSE 依然有优势，尤其是当它与像 Groovy 提供给 JDK 的扩展（称为 GDK）这样的语言支持增强结合时。

* Java Enterprise Edition 库。 没有任何技术能够比 EJB 对其社区产生更大的冲击，并且幸运的是，Java 社区看到了轻量级替代方案的兴起，Spring 和 Hibernate 提供了最后的例证，对这些场景来说，轻量级替代方案是理想选择。然而，如果暂时不考虑 EJB，Java EE 库就是非常成功的 — servlets 和 servlet 容器为遍及 Internet 和企业内部网的大量 Web 应用程序提供动力，JMS 提供对多种面向消息中间件系统的访问，JEE 领域中其他不太知名的参与者（如 JNDI） 毫无怨言地执行自己相应的任务。JEE 库很有可能受益于 API 重新设计，JSE 库就是这样，总体来说 JEE 库将满足 Java 程序员的需要。最大的问题往往在于认识何时首先需要 JEE 库。我们将在另一篇文章中讨论相关内容。

* Java-API-for-XML (JAX) 库。 尽管名义上是 JEE 库的一部分，但 JAX API 的数量和规模都在以与 JEE 其他部分不相称的速率增长，值得脱离 JEE 的上下文来考虑 JAX API。在近十年，尽管对 XML 支持的需求是巨大并且普遍的，但目前已经有所缓解，尤其是 Web services (WS-*) 周边领域和规范阵营（这些规范允许与其他技术之间实现普遍、轻松的互操作，包括 .NET）。在这里，Java 无疑需要某种类型的修订，由于 SAX、DOM 和 StAX API 经常需要更多的代码来完成重要任务，尤其是和具有更灵活的 XML 支持的语言相比时，比如 E4X、Ruby 或 Scala。此处，以 XML 为中心的思想有了明显的改变，从早期的 WS-* 实现中“不接触 XML”到基于 RESTful 方法的“我希望直接接触 XML 并将其定址为形式良好、有意义的 URI”，这种方法也强调了 JAX 领域内重构的必要性。在 Java 世界的地图中，这个区域被标注为“（应该）弃用的”。

* 客户端 Java。Sun 公司最近修订的“Java客户端”系统的测试版有个相当糟糕的名字 “Java SE 6 Update 10 Beta”，它提供了增强的客户端特性，包括新的 Swing 外观，称为 Nimbus。遗憾的是，在客户端度量 Java 的使用一直都存在问题，主要是因为专门用于度量的 applet 在 Internet 上已经使用了很长一段时间，还因为众多对 Web 托管应用程序的设计和架构关注点都以 HTML 的生成为中心，而不是生成现在所说的“富客户端”应用程序。随着采用速率的提高，Java 要经过漫长的旅程，追赶它在这个领域中的主要竞争对手，Flash 和微软在该领域新引入的技术 Silverlight 使情况变得更加复杂。Java 可能也会彻底失去阵地，这并不代表着这种平台的“消亡”，但会使问题恶化，当业内学者和商业杂志将其称为“Java 技术弱点的明显例证”时，一定要鼓舞自己！

* 服务器端 Java。 这实在不容争议：Java 毫无疑问是服务器领域内既定的参与者，特别是在查看非 Windows® 后端系统环境的选项时。LAMP 系列产品可能提供一个前端或垂直竖井的替代方案，包括 Ruby on Rails 也是一样，但观察重要的服务器计算基础设施时，Java 系列产品将占据显著的位置。事实上，正是这种领先地位促使微软最先积极地寻求 WS-* 规范，以使 .NET 代码至少能调用和配合既定的 Java 基础设施。微软最近认可了使互操作性向更正式的水平发展，他们在剑桥大学设立的“Interoperability Lab”也体现了这一点。

* 生态系统。 没有其他的平台拥有像 Java 平台一样如此丰富多样的生态系统，然而这经常会给 Java 开发人员带来一些麻烦（“我该使用哪种 Web 框架？”），事实上，很多 Java 生态系统都渗入其他环境，尤其是.NET。考虑 .NET 近来在微软内外获得的进步：ObjectBuilder（依赖性注入框架）、ASP MVC（基于 MVC 的 Web 框架）、NHibernate（Hibernate 的一部分）、NAnt 和 MSBuild（在句法或概念上与 Ant 相似的基于 XML 的构建系统）甚至 Silverlight 本身（在浏览器内部托管 CLR，允许执行更丰富的客户端）。在许多方面，.NET 生态系统为 Java 社区做了将近五年的后盾，因为 .NET 开发人员发现了与 Java 开发人员在五年前遭遇的相同痛点。而 Java 仍然坚持向 .NET 社区学习（比如统一通信 API 的有用性或显式轻量级工作流引擎的强大力量）。这只用来说明这些环境都正在互相学习这一事实，而且也表明，.NET 并没有使 Java 成为不必要的能力。

毫无疑问，Java 开发人员可以将他们自己的条目添加到这个列表中，证明这个论点：在 Java 平台中留有太多的优良的东西被认为“死亡了”或“将要死亡”或者甚至在“崩溃的边缘”。

王者终将归来

最简单的事实是：Java、平台、生态系统、环境和开发社区与死亡相去甚远，至少和目前正在使用的其他语言或平台距离一样远。即使是最严格的统计事实筛选也不能否认 Java 的领先地位。

此外，即使 Sun Microsystems 公司倒闭，平台也不会消亡。全世界的 Java 开发人员，联合起来！不要惧怕束缚的铁链：最终您将看到，这些铁链其实并不存在。多亏 Java 平台的开源，它现在被称为 OpenJDK，更不要说 Java 的其他开源“净室（clean room）”实现（Apache Harmony 和 Soy Latte 只是其中之二），即使 Sun 公司彻底从地球上消失，包括 IBM®、Apache、BEA 和 Oracle 在内的其他实体也能继续提供 JVM、库和工具，来支持整体生态系统。

Java 总有一天会消亡？绝对会的，但是我坚信 Java 的寿命会超过今天的程序员所使用的大部分语言，正如 COBOL 做到的那样。它甚至能比刚刚走出大学校园的第二代 Java 程序员走的更长。

“恐龙”，确实如此。

作者：Ted Neward, 主管, Neward & Associates

转自：http://www.ibm.com/developerworks/cn/java/j-cobol.html