译者｜Steve Hannah
翻译｜原子武器果汁
编辑｜燕珊
2004 年 google Maps 的问世标志着 Java 图形界面黄金时代的就此结束，也改变了图形界面环境下“虚拟化”的基本表述。
责任编辑译者以个人视点对 Java 图形界面发展心路历程做了简述，内容来自他在上世纪八十年代后期担任 Java 开发人员时的亲见欲求，主要讲诉曾经的“恶棍级”图形界面语言 Java 是为何从 21 世纪开始强势反弹逼人、步入衰落的。值得一提的是，译者现如今在做这款开发人员友好型 Java 图形界面部署工具（jDeploy），只不过他还是希望 Java 可以重燃魅力，再度变得对图形界面开发具有吸引力。
责任编辑是该简述系列该文中的第二卷，在中金该文中，译者简述了 Java 称霸图形界面的圣埃蒂安德如何在 1999 至 2005 的短短几年间接踵而至。原本的 Java 可谓丁元荐、凭 Applet 小流程艳惊五座，下定决心要在网络黄金时代下重新表述“图形界面”。网络的未来在于“跨平台”，而 Java 的血管中汹涌的正是“虚拟化”的血液，优势手握！可遗憾的是，事后来看，此虚拟化似乎并非彼虚拟化。接下来，让他们继续跟着译者的脚步去看看，具体在 2004 至 2007 年间，Java 图形界面又经历了什么。
图形界面王朝的最后时光
2002 年左右，我在客服人员中心为顾客提供计算机与印表机相关服务。我和小伙伴们挤在小小的饭厅里，面对着这款图形界面流程。通过这款应用软件，他们可以快速查阅顾客和商品重要信息，并把收发中的重要重要信息历史纪录进去。
在典型的客服人员发短信中，他们会询问顾客的商品序号，再把结果输出控制系统。如果他们以后就打过电话号码，控制系统就会输出窗口，里头包涵商品的完备历史历史纪录和以后的求救细节。在参考其他同事留下的情事历史纪录后，我还能快捷键中的工具栏和功能按键，例如帮顾客更换Note。
我不记得这款应用软件叫什么名字了，可能是为子公司或者客服人员中心专门订制的吧。印象里这应该是 PeopleSoft（Canillac子公司，2005 年已被金文收购）的商品，但我也不太确定。总之，这款图形界面应用软件运行在 Windows 2000 控制系统上，的确不是 Web 应用流程。它只不过挺复杂，里头包涵不少工具栏和配置文件；不过一旦上手，整个采用新体验相当棒——速度慢、反应敏捷，几乎没有任何延后。以输出电话号码电话号码查阅顾客历史纪录为例，他们只需要在“电话号码”表头里输出电话号码，其余盲点表单就会立刻被顾客重要信息充填完备。
，这款流程的确不是用 Swing 撰写的。但现如今全球各地无数子公司都在采用由 Swing 撰写的虚拟化图形界面应用软件，它们在采用新体验上跟我原本接触的这款流程非常相似。换句话说，Swing 已经满足了他们在 2001、2002 年那会对于图形界面业务应用软件的全部期望和想象。
在工作半年之后，上边来了新指示，要求他们用 Web 应用流程替换掉以后的图形界面应用软件。据说新控制系统会让他们的工作更轻松，但在第一节培训课刚刚过去十分钟后，他们就意识到这根本就是胡说八道：新控制系统简直烂透了！
我不太记得当时采用的是 IE 5.5 还是 IE 6 了，总之就是前 AJAX 黄金时代的 Web 环境。现在在商品表头中输出序号后，控制系统会弹出一个窗口，上面写着“正在加载……请勿关闭此窗口”。几出、再重新登录。
我不太理解子公司为什么要用这款“傻了吧唧”的 Web 应用流程替代以后的图形界面应用软件。可能是出于成本考虑吧，毕竟跟图形界面应用软件相比，Web 应用流程的开发和维护成本都更低。或者是应用软件供应商强行施压，比如“Web 才是未来，每个人都必须接受！”但，真有这么强势的乙方吗？
无论如何，这里透露出一个重要的重要信息：Web 应用流程还没等发展完善，就已经开始蚕食图形界面应用软件的生存空间。唯一的问题就是 Web 应用需要多久才能追平图形界面应用软件的采用新体验。而事实证明，用不了多久。
恐怖谷效应
再回到 Java 这边。热情的支持者们正不断扩大 Java 帝国的图形界面版图，对 WORA（一次撰写、随处运行）的热情也引导他们最终迈向虚拟化小流程与“本机”应用流程之间的秘密山谷。那时候的 Java IDE 主要面向三大构建目标：
1. 小流程
2. Java Web 开发
3. 可执行 Jar 文件
是的，没有直接开发本机应用流程的选项。虽然有第三方工具可以把 Jar 文件转换为本机应用流程，但这类工具相当复杂而且操作流程极为繁琐。只有对自己最“狠”的人才能坚持用得下去。而 Java 之所以有勇气忽视这一点，靠的就是对未来的判断——本机图形界面应用流程终于被淘汰。只不过这个预言是正确的，只是在时间上有所偏差。
从 2022 年的角度简述，Java 身上只不过有很多显而易见的问题。应用流程可以作为 Web 部署、也可以按本机部署，但这两种形式都没有一丁点“原生”感。Web 部署的小流程运行在自己的“沙箱”内并被集成到网页当中，整个运行过程又慢又迟钝。
HTML5 的崛起
虽然 Java 总想在 Web 和图形界面之间建起一道桥梁，但它自身却被 Web 所裹挟。到 2002 年，很多企业开始把原本的图形界面应用软件功能迁移到 Web 端。这些 Web 应用流程的构建、维护和部署成本确实比图形界面应用软件低得多，代价就是在用户新体验上做出妥协。
大约也是在这个时候，Java 开始推崇“富网络应用”的概念，希望把好 Web 应用跟差 Web 应用区分开来。但到 2004 年 Google Maps 正式亮相时，Java 的小把戏彻底宣告破产。Google Maps 以令人震惊的效果为富 Web 应用流程树立了标杆，而人家用的是 HTML5。
我最近又看了一次 Bill Atkinson 第一次向苹果爱好者们展示 MacPaint 的旧视频。在他第一次通过鼠标用画笔工具绘出图案时，现场一片“哇哦”和掌声。这就叫开创性。我第一次看到 Google Maps 也是类似的感觉，地图可以无缝缩放、万向平移，压根看不出来任何拼接的痕迹。这里采用的全新技术被称为 AJAX（异步 JavaScript 与 XML），这也是人们第一次能够在 Web 应用流程中向服务器后台无缝发出请求。现在这一切当然被视为理所当然，可 2004 年那会，开发人员需要绞尽脑汁才能把那些让人想吐的框架或者弹窗隐藏起来，确保不用刷新整个页面就能从服务器处加载新数据。
身为 Web 开发人员，我当然对其中的无穷可能性心生向往。但从图形界面开发的角度看，这场历史性的变革似乎没有给图形界面、特别是 Java 带来任何影响。
在 HTML5 以后，“虚拟化”的意思是“跨 Windows、Mac 和 Linux”，所以跨的范围还是在图形界面范畴之内。当时我并没意识到，但现在来看 HTML5 的亮相代表着新平台黄金时代的降临——它将成为顾客端应用流程的客观标准；更重要的是，Java 支持不了这个平台。突然之间，WORA 理念就出现盲点了——Swing 应用流程适用于一切平台，除了最重要的那个：网络浏览器。
Java 开发人员纷纷“外逃”
那 Java 图形界面开发人员们都跑哪去了？方向主要有三：
1. 服务器
2. 浏览器（HTML5）
3. 图形界面应用
如果大家对自己的基本定位首先是“Java 开发人员”、其次是“顾客端开发人员”，那最终应该会选择 Java 在当下仍然占据主动的平台——服务器。如果你对面向用户开发（顾客端）更感兴趣，而且主要看中 Java 的虚拟化价值主张，那接下来的目标很可能是 HTML5 （Javascript/HTML/CSS）开发。如果你是铁杆“保皇党”（比如说我），那就继续坚守 Java 图形界面开发，同时满腹狐疑地看着自己这个圈子越来越小。
GWT：让 Java 走进浏览器
2000 年初，JavaScript 开发工具尚处于起步阶段。大多数 Web 开发人员只能采用文本编辑器来撰写.js 文件。简单的验证脚本和交互设计倒是没问题，但这种粗糙的方法的确不能扩展并支持大型企业应用流程项目。另外，当时的 JavaScript 语言还不具备开发人员在重构等重要操作时所需要的功能，例如静态类型。
相比之下，Java 已经拥有一套全面的开发工具，能够轻松扩展至任何规模的项目。到 2004 年，领先且成熟的 Java IDE 已经成为开发环境中的标杆，其中的静态类型更是大大简化了大型项目的维护难度。到这时，唯一的遗憾就是 Java 应用流程无法在网络浏览器中运行（只有小流程可以）。
为了解决这个难题，Google 打造出 GWT（Google Web Toolkit）。这是一套 Java 到 JavaScript 的编译器加运行时库，允许开发人员借助 Java 那一整套领先的开发工具撰写应用流程，再把成果部署成 JavaScript 应用的形式在浏览器内原生运行。这套运行时库包涵诸多核心 Java API（例如 java.lang、java.util 等）的实现，确保业务逻辑能够在 GWT 应用流程与服务器应用流程间顺畅共享。
在用户界面方面，GWT 也提供自己的功能部件，只不过质就是以 Java 的形式将各部件与浏览器中的本机 HTML 部件相绑定。虽然他们还是没法直接采用 Swing 代码、大部分第三方库也不在支持之列，但他们至少可以用到自己最熟悉的 Java 开发环境和核心 API。
所以这不能算是让 Java 真正走进了浏览器——标准 JavaSE 库仍然大部分不受支持，线程等核心功能也无法起效。但至少对多数用例来说，这已经够了。
Google 用 GWT 开发出很多流行一时的 HTML5 应用流程，其中最著名的就是 Gmail，这个项目还催生出一个规模不大、但却相当活跃的开源社区。虽然影响力已经今非昔比，但这个社区直到现在也仍然存在。与此同时，JavaScript 工具的逐步改进也在挤占 GWT 的生存空间，过去十年来诞生的一系列更为现代的解决方案也允许他们在浏览器中更“无脑”地采用 Java。
服务器上的淘金热
HTML5 的出现颠覆了 Java 称霸图形界面的野心，但这里也有好消息。由于不必分神于图形界面端，Java 在服务器端迎来了全面发展。Java 做好了战斗准备、努力满足开发人员对后端服务的种种新需求——毕竟没有后端，再好的 Web 应用也出不来。
Java 在服务器端的受欢迎程度在接下来几年中持续增长，也吸引到整个生态控制系统的高度关注。第三方库不断涌现，而 2005 年 Maven 的诞生也让第三方库的采用不再复杂繁琐。无需额外下载、不必寻找依赖项，直接把片段粘贴到 pom 文件中，它就能自动下载一切相应依赖项。
Java 的开发工具也在不断改进，这在很大程度上要归功于 Java 在服务器端的优势地位。这些改进也对图形界面开发人员产生了积极影响，让他们用上了跟服务器端相同的 IDE、编译器、虚拟机和库。然而，代表 Java 世界“最后的坚持”的这帮图形界面开发人员眼界还是没能打开，仍在围着 UI 库的改进和部署打转。
遇到问题时，我的习惯是上 Google 搜一搜，看看有没有其他人遇到或者已经解决过相同的问题。但在 Swing 开发上，我发现最新的搜索结果也基本是 2005 年左右的内容了，之后基本再无新增。在找不到答案时，我偶尔会写一篇问题分析博文。而在两年后再次遇到类似问题时，我在 Google 上找到的就是自己两年前那篇博文……说真的，现在还有喘气的 Swing 开发人员吗？感觉真的说不好。
重新表述“图形界面应用”
从各个方面来看，Web 的兴起让“图形界面应用”的概念清晰了起来。Java 最初的虚拟化顾客端开发愿景并没有把瘦顾客端（主要与远程服务器交互）跟本机完备图形界面应用流程区分开来。这不仅提高了理解难度，更让安全模型的设计有些无所适从。Java 理解中的“平台”就是计算机本身，所以会采用笨拙的沙箱来限制可能引发安全威胁的 API 访问，例如访问文件控制系统。这是 Java 一切安全漏洞的根源，也是导致 Java 被逐出浏览器世界的原因。
这种基于“沙箱”的开发新体验相当糟糕，因为他们很容易意外“越界”并触发安全异常。最就此结束果是，几乎所有顾客端都会请求对控制系统进行“可信”访问，这样也就完全绕过了沙箱的限制。
相比之下，HTML5 在 Web 和图形界面之间设立了明确的边界。Web 应用流程默认无权访问顾客端计算机，而浏览器才是那个“平台”，这就让顾客端应用流程的安全保障变得更轻松、更易行。
经过此番变革，“图形界面”的范畴变得更小，以往很多被视为“图形界面应用流程”的应用软件现在被划入“顾客端应用流程”类别。具体来讲，如果应用流程只负责在用户与服务器交互时提供 UI，那它就属于顾客端应用流程。“图形界面”这个概念现在指的就是那些以某种方式与本机设备相集成的应用流程，包括访问文件控制系统（开发工具、文件转换工具等）、调用浏览器中不存在的某些平台本机 API、以及执行算力密集型任务的应用软件。
这倒不是说“客户端”应用流程跟“图形界面”应用流程间就毫无交集——当然有，这两者都涉及 GUI，而且不少现代图形界面应用流程也都需要接入服务器。所以无论是图形界面还是顾客端应用流程，都能享受到 GUI 工具包改进、媒体（音频 / 视频）及网络等技术层面的改进成果。
Java 图形界面的新征程
2004 年，我曾在 Mac 和 Windows 上都开发出一些商用级别的 Java 图形界面应用流程。HTML5 对这类应用流程基本没有任何直接影响。结合自身需求，Swing 还是完全够用，我用来构建本机捆绑包的各种图形界面部署工具也都能正常起效。
但很遗憾，科技行业就是个不进则退的世界。在接下来的几年中，Web 平台一路突飞猛进、而 Swing 却始终停滞不前。到 2007 年，Swing 已经到了不变革、就消亡的危难关头。它需要响应 HTML5 这波历史性潮流，而最终答案就是 JavaFX。这是一种新奇的 Java UI 工具包，能够把 Java 带入 GPU 加速、场景图、3D 图形、Web 视图的现代新世界，同时支持 MP3 和 MP4 等现代音视频编解码器。
在下一篇该文中，他们将简述 JavaFX 的火爆人气、深远影响，以及 2011 年 Mac 应用商店出现前 Java 领域的其他发展趋势。别小瞧 Mac 应用商店，它的出现堪称对 Java for Mac 图形界面开发生态的“斩首行动”。
（感兴趣的朋友可以多留言，InfoQ 将根据大家的需求继续翻译系列该文，以飨读者）
