Java混合化现状和RIA趋势分析

作者：  Bruce Eckel

        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不再提供免费版，也不提供电子版。

评论

2 楼 enboga 2008-07-21  

已经修改为转载

1 楼 ITeye管理员 2008-07-21  

转贴请不要注明原创，非原创文章请不要发布在博客频道首页。