【IT168分析评论】 我们不能等待Sun公司解决Java现存的一些问题……目前的解决方案就是引入一部分其它的语言，和Java混合编程。

    Bruce Tate有几本书集中写了关于Java的一些缺陷和放弃Java中那些还没有进展的观念的必要性。同时，还有这样或者那样的博客频繁出现，指出Java的一些缺点。当然，还少不了从Steve Jobs而来的流行语 ：“Java不值得安装，没有人将再使用它了。它已经成为一个巨大的拖累。

    这些言论的存在有其必要性，因为Sun公司死死抓住这么一个观念不放：Java无处不在，无所不能。不可否认，Java曾经是那么值得令人称赞的，但是，如今我们的赞美需要有所保留。因为一种语言要想获得更强大的生命力，那么它的设计者和提倡者需要承认客观问题。假装这是一种非常成功的语言，并能用在任何地方都是合适的，显然不是正确的。

    于是，不好的结果就发生了。最终，Sun公司还是得承认EJBs耗资巨大，EJB3开发小组从Hibernate和Spring那里学到了一课，但是不足以真正解决那些问题。不过大多数人发现Hibernate 和 Spring比EJB3更简单，更直接，而EJBs并不是短时间就匆匆问世的技术，那么它耗资巨大就不足为奇了。

    Java 5的出现，就是默认了Microsoft在C#上做了很好的语言改进，Java 7中被提议的一些特征，正好支持这种说法：Java和C# 3.0不分高下，同城竞技。竞争固然是好的，但是Java并没有消亡。它还需要改进，构建在Java虚拟机上的新语言如JRuby、Scala 和 Groovy，显示了Java的生命力。

Web开发局面一团糟

    能够看到事物的发展前途固然是好的，但是，当一件事物没有运行得很好时，人们通常不想去承认这个事实。Web的观念是梦幻般的，但是许多的web开发是失败的。没错，我们有能力使得网站运行。但是，我们很难说它运行很好。特别是，那些应用程序，使用HTML, CSS 和 JavaScript技术，它们很难开发，并且也很费钱，另外，在不同的浏览器之间，要想使得它们看起来完全一样，是一件不可能的事情。由于字体和字形的原因，即使一个简单的页面看不起来也不相同。

    不知道你是否用过Firefox，有多少个网站你访问得到，但是是不可读的页面，因为这些网站专门为Internet Explorer (IE)浏览器所创建的。就我看来，事情正在越变越糟了；我看见的东西多了，不光是一些网站在Firefox浏览器下不能运行……就这点来说，我正考虑重新使用IE浏览器。

    曾经CSS信誓旦旦，现在它也没有成功。多少年后，在不同的浏览器上它的执行结果仍然不一致。只要你使用HTML、CSS, 你就要经常考虑你所创建的网页将会在不同的浏览器上产生不同的效果，令人不爽。在IE 或者 Firefox 浏览器还好，另外的浏览器显示的效果会更差劲。

    在互联网的初期，JavaScript曾经是那么的有效，但是后来浏览器使得JavaScript不相容，因此使用起来很痛苦。Ajax成功的关键原因在于它的工程师不怕麻烦，解决了跨平台JavaScript的问题，以至于你不会察觉不同浏览器之间的会产生严重不一致性的问题。

    采取这种方法有两个问题。第一个问题是它受JavaScript脚本本身功能的限制。虽然Ajax是一个非常完美的工具，但它仅仅是一个工具而已，它的生命力不会很长。第二个问题如果你过于依赖Ajax库来处理跨浏览器问题。如果你想写你自己的代码，你必须成为那些问题的专家，那么就这一点而言，Ajax杠杆作用就不存在了。Ajax提高了用户体验，但是它拥有局限性，我怀疑我们已经发现了Ajax将会出现的一些弊端。

    给我印象很深的Google的Google Web Toolkit (GWT)，它能将选定类型的Java代码翻译成跨平台的JavaScript，以此来加速开发过程。你使用Java编码，那么GWT就可以将它们编译成跨浏览器的JavaScript。随后，JavaScript将变为中间代码运行在所有的平台上。但是，Google的智囊团首先需要解决那些不应该发生的问题。并且如果你所需要的库不存在的话，你必须又得成为一个跨平台的JavaScript专家来写你的代码。现在看来，GWT仍然才华横溢，闪闪发光，但是我认为它总有一天会江郎才尽，因为JavaScript固有的局限性和那些存在的不同浏览器。

    我们都看到了基于AJAX的工具，如GMail和其它的Google工具，它们慢慢的开始在诱惑我。它们都很好，但是这些东西都是你最想在web页面上看到的吗？当你仔细看这些应用程序，你就发现它们运行起来并不始终如一（我知道Google这些工具仍旧是测试版）。举个例子，在GMail中，当你按下键，如“r”时，应该是可以回复一条消息的。但是这有时可以，有时不可以，不知道问题出在什么地方了？当我使用web应用程序如GMail，我越来越发现“control +c”复制操作失效。或许是Firefox、JavaScript 或者是其它的出现了问题，但是我觉得这和web应用程序有关，这种问题出现了至少一年了。坦白的讲，我并不关心发生的原因，也不关心其它的用户是否也发生这样的事情。但是，像这类简单的事情发生了，我觉得它的前景堪忧。

    对于如今web开发中，存在众多的被误导的决策，我们需要做多大的努力才能补救？富客户端应用程序

    从某中程度上说，我们要扪心自问，Java applets为什么没有作为RIA的客户端的标准，在互联网上盛行起来？

    这是一个非常令人痛苦的问题，因为Gosling和开发团队急匆匆的将Java推广出去（因此铸就成许多欠考虑的决策），以便使得互联网发生革命性的变化。这就是为什么AWT和Applets为什么在最后时刻才出现，据说从提出概念到完成，只用了一个月的时间。Bill Venners 引用 Patrick Naughton如是说：“那是个时间问题，时间太紧，我们几乎不能完成它”。我以前也听到过这样的言论，当你在构建一种编程语言的时候，急功近利的态度在任何时候都是错误的。你创建了最基本的结构，然后你希望人们将会采用并且使用很多年。这需要深思熟虑的，并不能急于求成。

    我知道为什么Green团队采取了这个决策：像Microsoft一样。首先打出一个产品出去，为了把你吸引到window上来。这个产品不需要完美；仅仅需要垄断市场而已。随着时间的过去，你能够修补那些缺陷，是由于急匆匆的打出新产品而留下来的缺陷。这样的做法像市场版本下的敏捷开发方法。

    这种方法同样适合动态语言。曾今风靡一时的VB,就是通过许多年的发展才完善的。Python已经修复了很多的东西，目的是为了净化新的语言。据报道，Ruby将会采取同样的方法。

    但是，对于静态语言，特别是有大量编码基数的语言，想修补一些东西是很困难的。所有的代码必须重新编译和改变——虽然我建议Java可以采取Python的方法：如果你不想改变的话，不需要升级的话也可以运行。现在就有许多公司就不去升级到新的Java版本。

安装问题

    Java已经发展了10多年了，而applets并不是我们和互联网交互的主流方式。我认为主要的原因是安装的问题，这是Java的另一个欠考虑的方面。我们为什么喜欢Ajax?

    我们喜欢Ajax，显然不是因为JavaScript很容易使用——JavaScript曾因为存在的跨平台的问题，过去人们避免去使用它。Ajax之所以流行，是因为我们知道它在客户端所需要的软件已经安装了。如果有人解决了JavaScript如何跨平台的问题，并且假设安不安装JRE无关紧要，那么今天我们每个人可能在使用Java applets。但是事实上不是这样的，applets并没有无处不在，每个人现在正热衷于Ajax。这就是为什么Ajax称为RIAs的宠儿。

    虽然随着ECMAScript的标准化，JavaScript情况有所好转，我仍将用Java而不是JavaScript编程，主要原因还是其不一致性的原因。或许过了八年后，当前版本的ECMAScript成为所有浏览器的标准。尽管其具有随机执行特性，但是目前版本的JavaScript已经生效，并且安装问题为零，而Java还是没有称为主流，这就是很好证明：Java没有作为RIA语言的选择的原因就是安装的问题。

    这些年来，Java尝试了很多的补丁，但是我认为最基本的问题的是谁能够解决安装的问题，这是更为关键的内在技术，而不是外在的关注用户体验问题。

    举个例子，由于安装的复杂问题，我安装的早期Linux分布系统被侵袭过。大约一年后，我正准备重新安装Linux的时候，我就立即问自己一些问题。这些问题只有知道Linux核心部分的技术人员才能够解答。我不敢冒充自己是Linux高手，于是放弃安装，在第二年才重新试了一次。接着Red Hat的到来（至少我认为他们是第一个关注安装用户体验的），我在安装的过程中没有提出任何问题，或者至少给了我一个合理的默认解答。这就是为什么Linux开始流行的原因（最近，Ubuntu似乎准备解决Linux用户友好的问题）。

    安装JRE需要终端用户选择回答一些问题。对于一个技术人员，问题的答案是非常简单或者显而易见的，但是对于其它的web用户者，在安装过程中出现的问题会吓退他们。这里有一篇文章，及其评论，例证了安装Java时的一些问题。虽然这篇文章大部分抱怨更新问题，有一大堆的疑问是关于如何更新老的Java版本。

    JNLP，又称Java WebStart,本应该是解决简便安装桌面应用程序问题的。我认为JNLP没有被广泛的使用有其原因的，可以看看这个网站（https://aerith.dev.java.net/），其中有一个页面叫“Cool JavaOne Demos.”如果你点击这个页面上的JNLP 超链接，它就会开始启动，下载一堆东西，并且询问你一些问题。随后，什么也没有了。没有错误信息，也没有告知你当前的任何信息。重复尝试，产生同样的结果，只是整个过程变快了，因为所需的文件已经下载到本地了。至少，这是我的体验。如果者也同样发生在你身上，我不得不说这甚至更糟糕——这种情况只是随机的在一些平台上发生。这样一来，你就无法找出问题的所在。

    使用Java来构建GUI应用程序是不可能的，10年已经过去了，仍然存在applets、Java WebStart、常规应用程序的安装问题。再过十年，人们将不会相信什么了。如果不是过了10年问题还是这样的话，我今天说这些话将会处于孤立无援的地位，并且我会说你们没有考虑到这些问题的重要性。目前即使他们做了改进，仍然存在许多的不好的用户体验问题，给用户造成了不好的印象，如果想重新获得用户的信赖的话，需要很长的时间了。Java Applets应用程序体验

    对AWT最初的用户体验打击了我对Java的狂热，我不认为applets会起死回生。结果是Java从来不会成为RIA的主流。

    即使是现在，访问使用Java applets做的网站的时候，获得也是很差的用户体验。错误就是错误，没有错误的任何线索。更糟糕的是，这些网页会残留一些东西阻碍Firefox打开新的窗口，直到我重启为止。

    对于“applets已经消亡”言论的通常反映是“不，它们还存在，我仍在使用它们。”Applets不是没有用武之地；人们还在用它们创建一些令人印象深刻的东西。Java Posse每周还集锦一个或更多的applets应用程序。我想言论应该这么说：“对于RIAs，applets已经消亡”。对于依靠applets来建立一个通用的网站来说，是有很大的风险的，因为不仅是一些特殊applets稳定性不可靠，而且JRE的安装过程也是一个问题。

    桌面应用层程序也受到影响，给Java贴上了一个坏的标签，随着applets一起受到玷污。我使用过一个Java产品，叫Memorex exPressit，给我很坏的体验。用户接口界面非常难看，别且bug很多。给我带来鲜明对比用户体验的是Logitech的IO Pen后台软件（在.net平台下编写），这个软件运行起来很明了，很好看。你或许会说Memorex程序员有经验，但是这个Logitech公司的软件只是一个小的应用程序，没有费很大的力气就做的如此之好，反之，无法想像如果用Java编写的软件，用常规方法，不做更多的处理的应用程序会是什么样子？Eclipse是软件中的杰作，我认为之其中凝聚了极大的努力才达到了现在的程度。

    想想Corel用Java编写了文字处理器所做的努力。他的做法未免太早了，因为他当时可用的只是AWT。当然这是后车之鉴——如果你当初听信了Sun公司市场上的广告，你或许觉得你的选择是对的。对于这类的应用程序根本没有人用Java编写。

    OpenOffice不是用Java编写的，而是用C++。我不相信那是因为程序员为了努力追寻跨平台问题而瞄准C++.。那是因为速度，或许有直接的需求，需要控制底层平台。Java并不是所有问题的非常好的解决方案。

跨平台并不够

    我努力了很多年为了解决我的产品跨平台的问题，如产品Hands-On Java CD。和RIA存在相同的问题，因为我想让安装过程尽量简单，我想在第一次的时候能让所有的事情都无缝运行，我不想被迫去解决平台的问题。很多情况下我编写的软件表面运行良好，但是有时用户会发来email说他们的机器上的软件运行出错了。我不知道问题出在哪里。我最好的解答就是说：“在另一台机器上试试”，通常这样就能解决问题……无论问题出在什么地方。

    Java承诺的编写一次代码，任何地方运行是非常有吸引力的。不幸的是，至少当时是，没有得到Linux有效的支持。当时Linux 和 Mac 的用户还是少数人。

    Java缺少对MP3和其它多媒体的支持。就像Dick Wall所指出的那样，Java多媒体框架（JMF）被人们忽略很多年。我当时做了一个初步的论断，Java没有对任何压缩声音格式的支持。即使现在对MP3有支持的只是一些开源的软件，在概念上还是很不错的，我不想去测试它们，也不想去发现那些平台的问题——我只想它们运行良好；我只想从用户那里听到：“棒极了！”。

Flash解决方案

    首先允许我做这么一个假设：10年后，Java没有称为RIA世界的主流，而Ajax也没有流行起来，受到浏览器、HTML、CSS委员会强加的限制。那么此种情况将如何构建RIA了？

    明显的解决方案是Flash。Flash一直是跨平台的多媒体，有很好的用用户体验和用户接口。人们非常熟悉Flash,使用起来很舒适，它几乎能在世界上所有的机器上安装。它受人们信赖，它稳定，可靠。

    安装已经不成为任何问题。你不需要回答安装过程中出现的问题，或者做一些其它额外的东西；它自己运行安装良好。这就是为什么它无所不在的原因。当前Flash版本或者未来的Flash版本会在三种主要平台上同时发布（是的，除了64位的Linux除外）。标准的Flash安装能够播放MP3和其它的类型的视频。

    你不可否认Flash制作出令人愉悦的用户界面。Flickr和Picasa使用的是什么？不是Java，不是Ajax，而是Flash。Google videos,用Ajax编写，一定不可能在任何地方都能执行，因为他们收购了YouTube，而YouTube是用Flash做的。即使那些大多数顽固的Swing迷也背地里希望他们的UI好看些，特别是能够减少对Swing的额外工作。

    有一个非常有趣的Flash web应用程序叫做Gliffy ，它是模仿Visio（Visio是使用OpenLaszlo创建，稍后我将介绍）。虽然有人用HTML、 CSS 、JavaScript模仿做了一个简单的Microsoft Paint，但是没人能够想象的出用Ajax也能做出这些东西来。这就非常有趣了，因为你将从这些事例中看出这些技术所能达到的极致，然而，Flash才显露头角。另外着色复制（Paint clone）有些慢，并且UI在不同的浏览器之间会不一致。

    我们在惊叹在JavaScript范围之内的技术（如Ajax, JSON, GWT 等）所完成的杰出作品时，然而我们要认识到这都是有极限的。我们每天不断提高它们的极限范围，但是这些极限约束并没有消除。解决UI问题

    编程中的一个难点之一就是选择GUI库。有的时候有一个标准库，但是它总在变化。在Java中，我们首先使用的是AWT，而后来结果证明它是一个错误，以至于我们不得不耐心等待Swing的开发成功，直到IBM和Eclipse的出现，才给我们提供了额外的选择SWT。在Python中，有许多的GUI库，包括内置的Tkinter、WxPython、Qt等。基于操作系统的库也是一种选择，但是如果你想创建跨平台的应用程序，这些库就不可取了。

    如果你想涉猎这些GUI库的话，就像我一样，那么你必须冒学习更宽泛的知识，而不是更高深的知识。每一个库都需要很大的努力才能学会，每一个库似乎都有自己的一套体系，至于行为动作就很简单了。每一种库描述世界的GUI编程都是不一样的。

    我喜欢学习一种方案，让后将它运用到我所有的应用程序中去。我会停止学习GUI解决方案，而开始取学习一些高深的知识。理想状况是，有这么一种真正的语言，在不同的平台下，仍旧能够得到一致的结果。

    我相信要解决用户界面问题，我们需要一个具有多领域特征的语言的等价物，来致力于用户体验。对我来说，这个等价物就是Flex，它是基于Flash的技术，解决用户体验问题的出色方案。

Flex是什么？

    传统意义上说，Flash内容和应用程序由Flash工具创建，现在叫Flash 8 Professional。还有其它的工具叫Macromedia Director，为CD-ROMs而做的一个多媒体制作工具，它能制作Flash和输出一个Shockwave格式的内容，能在Plug-In/ActiveX上运行，非常像Flash内容，但是完全是不同的控制。Shockwave达到了全盛时期，现在仍被广泛使用，特别是游戏软件，但是Flash的重量更为轻载，并且取得了主流，远远超过Director。

    Flex是通过编程开发Flash应用程序的一种方法。它包括声明XML语言，调用MXML来布局用户界面，和一种叫ActionScript的编程语言，ActionScript是ECMAScript（标准化的JavaScript）的父集，还有一个特别的特征，有些像可选静态类型校验。ActionScript是一种单独的语言，能够在不同的平台上运行，你不需要担心不同平台的差异性。应为它是基于ECMAScript，你的JavaScript知识还能用得上。所有的MXML组件都是由ActionScript编写的，你还可以自己编写组件。Flex应用程序直接编译成SWFs（Flash二进制），随后在Flash运行过程中，编译时执行，以此获得很快的速度。

    最初我没有使用Flex主要原因是它的成本，主要来讲读者不愿意或者不能支付这个费用。在Flex的最初版本，你不得不购买服务器版本，仅仅是为了创建静态SWFs也不例外。那个服务器版本是为动态内容而设计的，对于大的组织，购买还是值得的，他们可以创建从数据库创建动态SWFs。但是，对于一个想对它进行实验的个人来说，购买是不理智的。对于我来说，如果你没有合理的实验路线，包括创建静态的SWFs来传送你自己的服务的目地话，我推荐你使用它很困难。

    然后，现在你可以下载免费的命令行Flex编译器来创建静态的SWFs，把你网站上的内容传送出去，不需要花一分钱。编译器，框架，调试器都是免费的，所以没有理由不去使用Flex。

    你可以使用Flex Builder 集成编译环境来帮助你创建Flex应用程序。这是建立在Eclipse平台之上（不是白手起家重新创建一个新的GUI开发系统，而是建立在别人的基础上发展——聪明的方法）。它具备我们所期待的通常的功能，如自动完成，上下文帮助，GUI布局工具。布局工具能够帮你快速设计，虽然我觉得手动设计会更好。

Flex作为DSL用于绘图

    Flex最为吸引人的事情是将UI作为创建Flash的首要解决的问题。这非常有道理，它是一个多领域的语言，能够用于绘画，多媒体，UI，相比较而言，其它的解决方案只是带了一个UI库，然后在应用程序中添加。

    由于设计的目标，Flex 和 Flash 提供了一个全美的，无局限的，灵活的工具来构建良好的用户体验。从程序员的角度出发，你只是学一种语言来构建UI，不需要考虑运行时的问题或者其局限性——问题诸如：
安装问题
创建时的约束问题
陡峭的学习曲线问题

    Flex有丰富的组件，你只需要拖下来使用就可以使用了——与Flex框架一起有100多了组件。组件的创建出现了很大的商机，无论是开源还是付费形式的。有这么一个组件来自Adobe：Flex制图组件（大约几百美元），但是仍有许多与之竞争的制图组件。

    Ajax最为有趣的一面就是它的异步行。这允许信息在客户端和服务器之间交互，而不需要页面的刷新。对于Flash来说，有一种比这还完善的技术，由Flex Data Services提供，一组数据管理发布/提交的API(publish/subscribe API)。Flex Data Services客户端和服务器之间自动完成高速缓冲技术和数据更新，产生一个最优的体验，而不迫使你写更多的额外代码。这可以让你获得实时数据，构建更大的应用程序，完成企业通信整合问题。你可以免费使用Flex Data Services在一个CPU上，如果你想你的应用程序使用多个CPUs，你就需要交费获得许可证。

    早先我提到过Gliffy，使用OpenLaszlo构建的。在Flex编译器和框架免费之前，OpenLaszlo非常吸引人。但是，OpenLaszlo组织决定将DHTML和Flash结合起来，这就引入了DHTML的局限性。Flex吸引我的就是它能让我从一些事物中获得它的优势和在任何地方都能产生同样的结果。Flex速度比OpenLaszlo快很多，因为Flex吸取了Flash 9 运行时编译执行的技术。现在Flex还是免费的，没有理由不去使用这个资源。