请注意，这里使用了 “首选” 编程语言一词，这意味着开发人员自己需要区别什么是他们的 “首选” 语言。考虑到大量的 XML 配置，使用 Spring/Hibernate/JSP Java 栈的开发人员可能可以很好地判断出 Java 不再是他们的首选语言。
注意过去六年中 Java 平台之上兴起的动态语言（Jython、JRuby、Groovy 甚至是 JavaFX），根据我和我的同事（“NoFluff 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）这样的语言支持增强结合时。
