java混合化现状和ria趋势分析

java抵触情结已经初步显现，我们已经开始看到由此引起的一些根本性转变。

bruce tate的一些著作集中讨论了java的缺陷，并指出需要放弃一些还未实现的想法。诸如jens alfke's thought palace和stephen colebourne's weblog中的博客也频繁提到这个问题。当然还有steve jobs的著名引用（引用自iphone）：“java不具有构建价值。人们不会再使用java了。它只是个巨大的累赘”。产生这种抵触的惟一原因就是，sun始终以为java是无所不在、无所不能。它曾经是令人叹服的，但是只有语言的设计者和提倡者能认识到其中的问题，这种语言才能继续发展。如果这种语言已经不再成功，仍然坚持称赞它，这种行为本身就是一种否认。ejb已经对此作出了反应。ejb3小组最终承认ejb成本太高，并且也从hibernate和spring学习了经验，但是还不足以解决问题。大多数人似乎都认为hibernate和spring比ejb3更加简单和直观，因此，对于这种过去成本过高的技术，很难再回到以前的看法了。

java 5默认了这样一个事实：microsoft使用ｃ＃实现了很多有趣的功能，而且java 7中引入的特性支持这样一种思想——java现在正与c# 3.0玩追赶游戏。竞争是不错的，java并没有死。它在继续发展，构建在jvm之上的新语言（如ruby、scala和groovy）的出现是java技术恢复活力的象征。我们想问这样一个问题：为何java applet未被当作ria（富internet应用程序）的客户端标准在internet上普及？这是一个非常尖锐的问题，因为gosling及其团队打算放弃java（从而摒弃许多考虑不周的决策），这将会引起internet的变革。这就是awt和applets在最后时刻被抛弃的原因，据说从计划到完成花了一个月时间。bill venners引用了patrick naughton的话：“这是一个时间问题，只需3个月时间就会波及整个java领域。这是由我们发起的。”我之前就听说过这句话1，而且在构建编程语言时，这种态度似乎总是错误的。您正在创建一个基本的体系结构，希望人们将会采纳和使用多年。这就是需要谨慎思索的地方，而不是冲动。

我能够明白为何green team持有这种态度：这是microsoft的方式。抛出一个产品以吸引大众的目光。这个产品不必是完美的；它只需要占领市场空间就行了。随着时间的推移，可以修复仓促推出的产品上的任何缺陷。这是一种敏捷的营销方式。这种方法适用于动态语言。曾经最流行的语言之一visual basic，已经发展了许多年了。python已经修复了一些对原有代码有害的缺陷，以优化该语言。据说，ruby也计划这么做。但是对于包含大量代码（特别冗长的语言）的静态语言来说，修复漏洞似乎不那么奏效。所有代码都必须重新编译，而且可能被更改，但是我认为，java本来也可以采用python的方法：如果不希望更改就不要更新。许多公司始终都没有更新其java版本。

1. 1 特别是当我编写thinking in java 时，许多人都说“已经有太多的java图书了，您的书不会有市场的，不值得这样做。”

web陷入混乱

能够发现可能性固然不错，然而缺点是很难确定何时出现故障。web的概念非常有远见，但大部分web是失败的。是的，我们已经能够使web工作，但是很难说它“运行良好”。具体来讲，使用html、css和javascript的任何应用程序都难于开发并且成本昂贵，而且似乎不可能在不同浏览器上获得相同的外观。甚至简单的页面也会因字体问题而看起来不同。

如果您使用firefox，有多少您访问的站点由于只针对internet explorer (ie)创建而至少有部分内容难以读取？在我看来情况越来越糟了；我看到更多（不是更少）站点不能很好地兼容firefox，以至于我将认真地考虑转向ie。

css并没有实现它许下的美好承诺。许多年过去了，它在各种浏览器上的实现仍然不一致。只要使用html和css，您就总是想知道自己创建的应用程序是否会在其他浏览器上产生不符合期望的效果。除ie或firefox之外，其他浏览器的情形还会更糟。

javascript也在web初期出现了，但是浏览器的混战导致了javascript的不一致性和难于使用。ajax的关键元素之一在于，已经有人开始解决跨平台javascript问题，因此您不用考虑不同浏览器之间经常出现的不一致。这种方法存在两个问题。第一个问题是javascript的功能有限。尽管ajax可以充分利用javascript的功能，但它的功能也非常有限。第二个问题是，我们依靠ajax库来处理跨浏览器问题。如果想要编写自己的代码，必须精通这些问题，而且到那时ajax的许多功能都没有用了。ajax极大地改善了用户体验，但它也存在局限性，我猜想我们已经了解了ajax将提供的绝大部分功能了。

更令人印象深刻的是google web toolkit (gwt)，为了加速开发过程，它将类型检查java转换为跨平台javascript。首先用java编写代码，然后用gwt将其编译为跨浏览器javascript。然后，javascript变成了能够在所有平台上运行的中间代码。但是这让google的智囊团不得不解决本来不应该出现的问题。而且，如果没有所需的库，您仍然必须解决跨平台javascript问题，才能编写新代码。纵使gwt如此高明，我觉得它也会被javascript和浏览器的内在限制搞得筋疲力尽。

我们确实看到了一些令人惊奇的基于ajax的工具，比如gmail和其他google工具，它们正在不断地诱惑我。这种现象非常好，但这是您希望在web上看到的最好结果吗？您已经看到，如果没有这个限制，这些应用程序就非常接近理想结果了，即使它们不能持续工作（是的，我知道google工具还“处于测试阶段”）。例如，在gmail中，您按下‘r’键后应该能回复消息。有时候这是可行的，但常常行不通，这非常使人恼火。而且更常见的情况是，当我使用像gmail这样的web应用程序时，ctrl-c复制操作也不起作用了。windows、firefox、javascript或其他软件中都会出现这种问题，但它似乎与web应用程序有关，而且这种情况至少持续了一年。坦白来讲，我并不关心为什么会出现问题，相信任何其他用户也不会关心。如果这么简单的事情都出现问题，其前途不容乐观。

对于造就了如今的web的一连串错误决策，我们必须付出多少努力才能补救？

安装问题

java已经存在10年了，而且applet并不是与web交互的主要方式。我认为主要原因在于安装问题，这是另一个未被重视的java问题。老实说，为什么我们喜欢ajax？

这显然不是因为javascript易于使用——javascript的跨平台问题是过去人们不愿使用它的原因。ajax的流行是因为，我们知道客户端已经安装了必需的软件。人们必须首先解决javascript的跨平台问题，但是如果java runtime environment (jre)很容易安装，所有人都只需创建java applet就行了。但事实不是这样的，applet没有这么流行，因而每个人都转向使用ajax。所以，ajax变成了大家喜爱的ria技术。

尽管借助ecmascript标准化会使情况得到好转，但是与javascript相比，我仍然更愿意使用java编程，主要原因在于javascript的不一致性。也许八年内当前版本的ecmascript将会成为几乎所有浏览器的标准。但是当前版本的javascript已经可以使用了（尽管其实现比较随意），并且不存在安装问题。我认为这很好地印证了一点：java未能接手ria语言的原因在于其安装问题。

尽管多年来已经对java进行了各种各样的修补，但我认为根本问题在于，所有尝试解决安装问题的人都只是站在技术的角度，而没有从真正需要的角度考虑：外部用户的体验。例如，我曾经被linux发行版困扰，因为它的安装很麻烦。我几乎每隔一年安装一次linux，而且一旦安装，安装程序就开始询问问题。只有精通linux的人才知道这些问题的答案。我甚至无从下手，因此只有放弃并在来年再尝试。然后red hat诞生了（至少，我认为它是第一个关注安装体验的产品），而且安装linux时不会询问问题，或者至少给出一些合理的默认设置。linux正是从那时开始流行的。（最近，ubuntu在解决linux的友好性问题上似乎处于领先地位。）

安装jre需要用户回答问题。对于精通jre的人来说，这些问题的答案很简单或者是显而易见的，但是对于其他web用户来说，这些问题会让他们不知所措。在文章sun never sets on java security updates中，infoworld的ed foster评论并举例说明了java的安装问题。尽管这篇文章主要是对更新的抱怨，但也对旧版本的java很不满。ryan tomayko也写了一篇博客，讨论了java的安装问题。

java network launch protocol (jnlp)是java webstart的基础，它本来应该解决这些问题,创建易于安装的桌面应用程序。我认为jnlp未被广泛使用的原因可以在https://aerith.dev.java.net/上找到，这是“cool javaone demos”的一个页面。如果单击页面上的jnlp版本链接，它将开始启动、下载一些东西并询问您问题。然后就没有下文了。没有错误消息或任何信息告诉你发生了什么。重复尝试还是会产生相同的结果，只是速度快些，因为需要的文件已经下载下来了。至少，我的体验是这样的。如果您能够正常使用，那么就更糟了——它只能随机地在一些平台上运行，而在另一些上就不行。这样的产品如何调试呢？

使用java构建gui应用程序并不是不可能，但是10年过去了，applet、java webstart和常用应用程序仍然存在安装问题。10年之后，人们不再信任它了。如果10年之后不会出现这种情况，我敢说某些人会认为这个问题不值得修复。即使他们修复了，由于用户已经有了如此多的糟糕体验，需要经过多年才能重新建立起之前的信任。

结束语

我们显然不能等待sun修复java的所有问题。最终，开源java也许会对修复java缺陷产生巨大影响。例如，java media framework (jmf)中的工作可能会恢复。或许有一天会修复安装问题。这完全有可能，但如果您现在就需要解决问题，那么解决方案是对该语言的各部分各取所长。我们已经这么做了。您没有坚持为一个应用程序使用一个数据库；您使用一个专门的系统，比如mysqloracle。sun能够直接支持针对混合java/jruby编程的jruby开发。我们将会看到其他具有特殊用途的语言将会出现，用以解决专门问题。如果专门的系统能够更好地解决这个问题，为什么要坚持为ui使用一个java库呢？

正如turbogears-flex demo i created with james ward所示，可能使用一种像python（或者java、ruby、c#或其他）语言作为后端并使用flex构建用户界面。这甚至可以在桌面应用程序上实现（使用即将发布的apollo工具能实现更多）。

关于作者

bruce eckel编写了许多关于计算机编程的著作和文章。他经常举行针对计算机编程人员的演讲和讲座，他是ansi/iso c++标准委员会的创建成员。他最著名的著作是thinking in java和thinking in c++，适用于面向对象编程经验很少的编程人员。大多数评论家都认为这些著作比大多数关于java或c++的介绍性文章更有价值，而且更加适用于教学。他的这两本著作都可以免费下载。但是，他的最新著作thinking in java, fourth edition不再提供免费版，也不提供电子版。