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的一连串错误决策，我们必须付出多少努力才能补救？
富Internet应用程序
我们想问这样一个问题：为何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版本。
安装问题
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年之后不会出现这种情况，我敢说某些人会认为这个问题不值得修复。即使他们修复了，由于用户已经有了如此多的糟糕体验，需要经过多年才能重新建立起之前的信任。
Java applet和应用程序体验
AWT最初的用户体验沉重打击了Sun对Java的狂热吹嘘，而且我认为applet到现在还未恢复元气。结果，Java永远不会成为RIA的主流。即使在现在，仍然不能在web站点上方便地运行Java applet。他们失败了，而且还不知道错在哪里。更糟糕的是，他们甚至会阻止Firefox打开新窗口，直到我重新启动计算机。
对“applet已经死了”的常见回应是“它们没有死。我一直都在使用它们。”applet并不是一无是处；人们仍然在用它创建出色的产品。Java Posse每周都会发布一个或多个applet。上面的论断应该理解为“对于web RIA来说，applet已经死了”。JRE和任何特定applet的安装过程并不足以说服任何人将它们用于通用的web站点。
Java的缺陷同样也影响到了桌面应用程序，applet也是一样。我曾经使用过一个叫做Memorex exPressit的Java产品，它的UI非常难看而且缺陷很多。我还使用过Logitech IO钢笔支持软件（用.NET编写的），它运行流畅而且外观漂亮，与Memorex exPressit形成鲜明对比。您也许会说Memorex编程人员缺乏经验，但是Logitech软件只是一个运行良好的小型应用程序，无需编程人员付出任何辛苦的劳动，然而，在我用过的使用Java编写的应用程序中，几乎没有一个易于使用。Eclipse是一款非常优秀的软件，但我觉得其背后一定饱含着“艰辛的劳动”。
Corel曾经试图使用Java创建一个文字处理程序（我忘记了他们是想移植WordPerfect还是从头开始编写）。显然他们的行动太早了，因为他们仅具有AWT。但是如果您听过Sun的夸张宣传，就会觉得这是正确的选择。不过没关系，无论如何它还是能工作的，因为这类失败已经使人们不敢使用Java了。
OpenOffice不是用Java编写的，而是用C++编写的。我相信这不是因为编程人员想要与C++的跨平台问题做斗争。而是因为C++快速，或许是因为可以更直接地控制底层平台。尽管发展方向始终由Sun掌控（多年以前，我参加了一个记者招待会，Gosling在会上说“Java始终跟C++一样快或者更快”，这句话一直困扰着我），但是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年之后不会出现这种情况，我敢说某些人会认为这个问题不值得修复。即使他们修复了，由于用户已经有了如此多的糟糕体验，需要经过多年才能重新建立起之前的信任。
跨平台还远远不够
多年来，我一直在努力解决像Hands-On Java CD这类产品的跨平台问题。这与RIA问题是相同的，因为我希望安装过程能够尽可能简单，希望所有功能都能够无缝运转，而且不希望遇到平台问题。我的解决方案在很多情形下能够生效，但有时客户会给我发电子邮件说，这种方案在他们的计算机上行不通，我不知道问题出在哪里。我能做的最好的事情就是让他“在其他计算机上试试”，而且这常常能解决问题……无论是什么问题。我永远不希望听到这类问题；我只希望所有功能都能够生效。
我的主要目标是创建一个slide-and-audio内容交付系统，就像您在Hands-On Java CD ROM或Thinking in C中看到的一样。Java曾经宣称“只需编写一次就能在任何地方运行”，它是一个很有吸引力的竞争者。不幸的是，Linux对它的支持来得太晚了（而且Mac的支持也比较晚）。Linux和Mac用户也许只是少数，但是他们能直言不讳地提出意见。
遗憾的是，Java不支持MP3和多媒体。正如Java Posse的Dick Wall曾经多次指出的，Java Media Framework (JMF)被忽略了许多年。在我最初做决定的时候，没有对任何压缩声音格式的支持（与MP3相比，我更喜欢使用其他格式）。即使到现在，也只有开源软件能够支持MP3，理论上讲很不错，但是我不想对其进行测试并找出平台问题——我希望它能够运行；我惟一希望从客户那里听到的回应是“这太好了！”
似乎惟一能够使用的只有RealPlayer，所以我使用它播放第二版的HOJ CD。但是RealPlayer在安装过程中总是试图让您购买付费版本；我必须告诉人们如何找到免费版本。而且它非常霸道——它取代了MP3，尽管您告诉它不要这么做。
尽管如此，RealPlayer也不可靠。它的安装偶尔会出现问题，我收到了很多这样的电子邮件。我不知道问题的根源，而客户通常会认为是CD出了问题。Daily Show使用RealPlayer多年了，它不但因为总是开始和停止而使人苦恼（所有媒体都不能预先下载，只能在线观看），而且在图片左侧总是存在拖尾。现在Comedy Central已经转变为一个新系统，但这只能间歇性地运行。所以我只能期待它们在YouTube上发布了。
Flash解决方案
所以，这就是我的问题。可能10年之后，Java仍不能够占领RIA领域。可能Ajax只是“JavaScript本来期望的运行方式”，但是浏览器、HTML和CSS的局限性似乎限制了它的发展空间。我们将使用什么来构建RIA？
对于我而言，我只是希望有这样一个系统，它能够解决我的所有 UI问题，而不只是一些问题。如果我打算学习它，我不希望在开始开发时却碰壁了。这种情况已经发生很多次了。显然，惟一的解决方案是Flash。Flash总是与所有跨平台多媒体体验和用户界面相关。人们非常熟悉和喜欢Flash，而且它安装在几乎所有计算机上。它值得信任、稳定而且可靠。
Flash的安装对于每个人来说都非常简单。不需要回答问题或执行特殊操作；它运行良好。这就是为什么它这么流行了。当前和以后的Flash版本都会在3个平台上（是的，除了64-bit Linux，但是正在解决这个问题，而且其用户通常都有不止一台计算机，因此他们还有备选方法）同时发布。标准的Flash安装能够播放MP3和各种视频类型，因此不用担心“编写一次就能在任何地方运行……除了用于多媒体”。
而且不可否认，Flash产生的用户界面非常友好。Flickr和Picasa都使用什么？不是Java、不是Ajax，而是Flash。Google Video是用Ajax编写的，它肯定不能用于所有地方，因为他们购买了使用Flash的YouTube。甚至最顽固的Swing支持者也暗地里希望自己的UI能有这么漂亮，尤其是不需要Swing要求的所有额外工作。
有一个非常不错的Flash web应用程序叫做Gliffy，它效仿了Visio（它是用OpenLaszlo创建的，我将在稍后提及）。没有人能够想到用Ajax创建这样的软件，即使使用HTML、CSS和JavaScript模仿更加简单的Microsoft Paint的人也想不到。非常不错，但是您会认为这已经接近这些技术的功能极限了，而Flash才刚刚开始。除了Paint克隆有点缓慢和笨拙之外，各个浏览器上的UI也不一致。即使在JavaScript和诸如Ajax、JSON、GWT和其他技术的限制内完成了令人惊讶的成就，仍然存在着限制。我们每天都要面对这些限制，但是它们并没有消失。
解决UI问题
GUI编程的一个困难之处在于选择GUI库。有时候有一个标准库，但是不能进行更改。在Java中，我们首先使用AWT，后来证明这是错误的，因此我们不得不忍受开发出来的Swing，直到IBM和Eclipse加入并提供了一个额外选择SWT。在Python中，有许多GUI库，包括内置的Tkinter（它克服了安装问题）、WxPython、Qt等等。特定于Windows的库也有类似的选择，但是如果想要创建跨平台应用程序，这些库都用不了。
如果研究这些GUI库，跟我一样，您需要获取大量不是很深入的知识。每个库都需要花时间学习，每个库都有自己的特点，某些活动在一个库中非常简单，但是在另一个库中只是有可能实现。每个库都用不同的方式看待GUI编程。我宁愿学习一种解决方案，然后用于所有的应用程序。通过这种方法，我就不用学习GUI解决方案，然后开始深入研究。理想情况下，这将会是一个在所有平台上都产生一致结果的真正的编程语言。我相信要解决用户界面问题，需要一种专注于用户体验的特定于域的语言。对于我来说，基于Flash技术（比如Flex）是此问题的最佳解决方案。（我正在安排与Adobe签订一份顾问协议，以帮助他们向大众培训Flex的知识。但是很久以前我就确信Flash，特别是Flex是用户界面问题的最佳解决方案，在Adobe表示对我的帮助感兴趣之前我就开始编写这篇文章了）。
什么是Flex？
一般而言，Flash内容和应用程序是使用Flash著作工具创建的，该工具的当前版本为Flash 8 Professional（这容易混淆，但是在10年前就决定为这个工具赋予与运行时相同的名称了）。还有一个工具称作Macromedia Director，这是一个针对CD-ROM的多媒体制作工具，它比Flash更早，输出一种Shockwave格式的文件，这种文件在一个插件或ActiveX控件中运行，这种控件与Flash内容很相似，却是一个完全不同的控件。Shockwave也有自己的强盛时期，而且一直都被广泛使用，特别是在游戏中；但是Flash比Shockwave更轻量型，而且应用更加广泛。
Flex是一种通过编程开发Flash应用程序的方式。它包括一种叫做MXML的说明性XML语言和一种叫做ActionScript的编程语言，前者用于用户界面布局，后者是ECMAScript 的一个扩展集（也就是标准化的JavaScript），还包括一些额外特性，比如可选的静态类型检查。ActionScript是一种跨多平台运行的语言，因此无需担心各个平台的差异。由于它基于ECMAScript，所以JavaScript知识能够派上用场。所有MXML组件都是用ActionScript编写的，如果想要编写自己的组件，也可以使用它。Flex应用程序被直接编译为SWF（Flash二进制码），然后由Flash运行时进行Just-In-Time (JIT)编译，这可以提升其速度。
成本是最初阻碍我使用Flex的主要考虑因素，主要是因为读者都不愿意或无法支付这些费用。在最早版本的Flex中，必须购买服务器版本才能创建静态SWF。服务器版本是针对动态内容设计的，对于从数据库或类似程序创建动态SWF的大型企业来说，花这些钱当然是值得的。但是对于只想尝试一下Flex的人来说，没有理由花这些钱。如果一般人没有一个合理的实验方法，包括创建静态SWF以从他们自己的服务器交付，那么我将很难推荐Flex。但是，现在您可以下载免费的命令行Flex编译器创建静态SWF，也可以从您的web站点交付这些SWF，无需支付任何费用。编译器、框架和调试器都是免费的，所以没有理由不使用Flex。
可以购买Flex Builder IDE帮助创建Flex应用程序。这是构建在Eclipse平台之上的（而不是从头创建一个新的GUI开发系统——一种明智的方法）。它拥有我们预期的常用功能，比如自动编译、上下文帮助、调试，以及GUI布局工具。开始设计时，可以使用布局工具快速入门，但是我发现，设计好草案之后再进行手动调优会更有用。
以下是我过去遇到的一些问题：尽管针对Windows和Mac的Flash播放器总是同时发布，但是针对Linux的Flash的发布时间会晚很多。我最初不知道，直到我推出了Thinking in C eSeminar的第一个测试版并收到Linux和Mac用户对Flash的抱怨时才知道。通过一番调查之后，我决定向后移植应用程序（这是可行的，而且Flash 7包含了所有需要的功能）。这对于我来说似乎是最好的解决方案，因为我不需要等到新版本的Flash发布，而且不用担心Linux。我使用Flash的一个主要目的是让应用程序具有跨平台的透明性，以及将安装问题最小化。但是，Flash 9及其以后的版本，所有播放器的发布间隔只有数周，Flash的后续版本也会采用这种策略。因此现在您不用担心任何人抱怨了。使用Flex构建您的UI，它一定会“正常运行”。
将Flex用作图形DS
Flex的一个最吸引人的地方是，Flash一开始就是根据UI的思想创建的。在一个非常真实的感觉中，它是一种针对图形、多媒体和UI的特定于域的语言，而大多数其他解决方案都是一种后来才添加上UI库的语言。由于这个设计目标，Flex和Flash提供了一种用于构建用户体验的完整、无限制、灵活的工具。从编程人员的时间投资立场来看，您只需学习一种用于构建UI的语言，无需担心以后碰到问题或限制——问题包括：
• 安装问题
• 功能限制
• 陡峭的学习曲线
可以使用许多奇特的组件——Flex Framework（免费下载的一部分）附带了超过100个组件。还有一个活跃的组件创建者市场，包括开源的和付费的。Adobe创建了一个这样的库：Flex Charting Components（在几百美元以内），但是还有很多吸引人的图表组件。
当然，Ajax的一个最有趣的方面在于，代表“异步（asynchronous）”的“A”。这允许信息在客户机和服务器之间流动，而无需刷新整个页面。对于Flash，Flex Data Services 提供了一个更完善的版本。这是一个用于数据管理的发布/订阅API。Flex Data Services在客户机和服务器之间自动执行缓存和更新，无需编写额外的代码就能产生最佳的用户体验。这允许处理实时数据、构建协作应用程序，以及集成企业消息传递。可以在单个CPU上免费使用Flex Data Services；如果您的应用程序需要多个CPU，那么您会被当作一个企业，并且需要一定的许可费用。
我之前提到过Gliffy，它是使用OpenLaszlo构建的。在Flex编译器和框架变得免费之前，OpenLaszlo非常有吸引力。但是OpenLaszlo小组已经决定，他们将通过将DHTML与Flash结合提供大多数人能够接受的技术，这消化了DHTML的局限性。Flex吸引我的原因是，它允许我执行在常用浏览器中不能执行的操作，而且无论在哪里，这些操作都会产生相同的结果。另外，Flex比OpenLaszlo发展更快，这是因为它利用了Flash 9中的JIT编译器。因为现在Flex是免费的，没有理由不使用它。
桌面上的Flex
当然，如果我的梦想是能够深入学习一种GUI系统，那么这个工具会是Flex吗？因为它最初就是设计用于web RIA的？
Flex UI可以发起与它的服务器或者它选择的任何其他服务器的通信。服务器不能发起与Flex UI的通信，这一点很重要，因为可以保证安全性（这类似于计算机上有一个开放端口）。
但是，Flex UI不仅能够与服务器通信，它还能与本地应用程序通信。因此，可以用自己喜欢的任何语言（甚至是像Python或Ruby这样的动态语言）创建应用程序，然后使用Flex构建一个漂亮的UI。
Adobe正在开发一个叫做Apollo的新工具，这是一个跨OS运行时，它支持使用Flex创建桌面RIA。这意味着您的Flex技能可以进一步用于创建流畅的桌面应用程序，而且它也意味着可以更轻松地构建在web和桌面上都 能运行的应用程序（我曾经见过支持其他语言来实现这个功能的昂贵且难用的工具）。
结束语
我们显然不能等待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工具能实现更多）。
更多信息
您可以在Adobe.com web站点和http://www.flex.org/上了解关于Flex的所有信息。这是一个非常丰富的站点，其中包含大量示例、教程和屏幕录像。它们甚至有一个在线Flex编译器，可以立即尝试。还有一个James Ward提供的关于使用Flex开发的深入演示文稿。还有另一个正在制作的屏幕录像，展示了如何将Flex作为Java服务器应用程序的前端使用；当它完成之后，我会在Developer Center中通知大家。下载Flex（试用或者购买）。您现在可以在服务器（可以在其硬件上运行Linux）上创建低成本、功能强大的Java组合，以及在客户机上创建交互式Flash界面。
关于作者
Bruce Eckel编写了许多关于计算机编程的著作和文章。他经常举行针对计算机编程人员的演讲和讲座，他是ANSI/ISO C++标准委员会的创建成员。他最著名的著作是Thinking in Java和Thinking in C++，适用于面向对象编程经验很少的编程人员。大多数评论家都认为这些著作比大多数关于Java或C++的介绍性文章更有价值，而且更加适用于教学。他的这两本著作都可以免费下载。但是，他的最新著作Thinking in Java, Fourth Edition不再提供免费版，也不提供电子版。