作者｜Steve Hannah
翻译 | 核子可乐
编辑 | 燕山
2004年谷歌地图的推出标志着Java桌面时代的结束，改变了桌面环境下“跨平台”的基本定义。
本文作者从个人角度回顾了Java桌面的发展历程。 内容来自于他在 1990 年代后期作为 Java 开发人员时的所见所闻。 开始出现衰退迹象，进入衰退期。 值得一提的是，作者现在正在开发一个开发人员友好的 Java 桌面部署工具（jDeploy）。 其实他还是希望Java能够重拾风采，重新对桌面开发产生吸引力。
在这篇回顾系列文章的第二篇文章中，作者回顾了 Java 的桌面霸权承诺是如何在 1999 年到 2005 年的短短几年内土崩瓦解的。在 Java 诞生之初，可以说是满满当当雄心壮志，其Applet技术震惊了所有人。 立志重新定义互联网时代的“桌面”。 互联网的未来在于“跨平台”，Java的血管里涌动着“跨平台”的血液，优势在手！ 不幸的是，事后看来，这个跨平台似乎并没有跨平台。 接下来，就让我们继续跟随笔者的脚步，看看2004年到2007年间，Java桌面发生了什么。
桌面王朝的最后时光
2002 年左右，我在一家呼叫中心为客户提供计算机和打印机技术支持。 我和我的朋友们挤在一个小隔间里，面对一个桌面程序。 通过这款软件，我们可以快速查询客户和产品信息，并记录通话中的重要信息。
在典型的客户服务电话中，我们会询问客户产品的序列号并将结果输入系统。 如果他们以前打过电话，系统将输出一个窗口，其中包含产品的完整历史记录和以前求助电话的详细信息。 参考其他同事留下的原因记录后，我还可以操作界面中的选项卡和功能按钮，比如帮助客户更换新机器。
这个软件的名字我不记得了，可能是专门为公司或者客服中心定制的吧。 我的印象是这是一家 PeopleSoft（PeopleSoft 公司，2005 年被 Oracle 收购），但我不确定。 总之，这个桌面软件运行在Windows 2000系统上，当然不是Web应用程序。 其实挺复杂的，有很多菜单和表格； 但是一旦你掌握了它，整体体验就会非常好——快速、响应迅速，几乎没有任何滞后。 以输入电话号码查询客户记录为例。 我们只需要在“Phone”字段中输入号码，其余空白表格将立即填写客户信息。
据我所知，这个程序肯定不是用Swing写的。 但是今天，全世界无数公司都在使用用 Swing 编写的企业级桌面软件，这些软件在体验上与我介绍的程序非常相似。 也就是说，Swing 满足了我们在 2001 年和 2002 年对桌面商务软件的所有期望和想象。
工作了半年，上面又来了新的指示，要求我们把以前的桌面软件换成网页应用。 据说新系统会让我们的工作更轻松，但在第一次培训课程开始十分钟后，我们就意识到这是胡说八道：新系统糟透了！
我不太记得我使用的是 IE 5.5 还是 IE 6，但无论如何它都是 AJAX 之前的 Web 环境。 现在在产品字段中输入序列号后，将弹出一个窗口，显示“正在加载…请勿关闭此窗口”。 几秒钟后，窗口自行消失，客户详细信息出现在表单中。 无论如何，每当需要从服务器获取某些东西时，就会弹出这个倒霉的窗口。 领导还提醒我们不要随便点击浏览器的“刷新”，说这样会破坏系统状态。 所以每当出现问题时，我都必须注销并重新登录。
我不太明白为什么一家公司会用这个“愚蠢”的网络应用程序取代他们以前的桌面软件。 可能是出于成本的考虑，毕竟 Web 应用程序的开发和维护成本比桌面软件要低。 或者软件供应商对其施加压力，比如“Web 是未来，每个人都必须接受它！” 但是，真的有这么强大的乙方吗？
不管怎样，这里透露出一个重要信息：Web应用还没等发展完善，已经开始蚕食桌面软件的生存空间。 唯一的问题是网络应用程序需要多长时间才能与桌面软件的体验相匹配。 事实证明，这不会花很长时间。
恐怖谷效应
回到 Java 方面。 热情的支持者正在扩大 Java 帝国的桌面足迹，他们对 WORA（编写一次，随处运行）的热情最终将他们带到了跨平台小程序和“本机”应用程序之间的秘密山谷。 当时的 Java IDE 主要针对三大构建目标：
1.小程序
2. Java Web 开发
3.可执行的Jar文件
是的，没有直接开发本机应用程序的选项。 虽然有第三方工具可以将Jar文件转成原生应用，但是这类工具相当复杂，操作过程也极其繁琐。 只有对自己最“狠”的人，才能坚持使用。 而Java有勇气无视这一点，靠的是对未来的判断——原生桌面应用终于被淘汰了。 其实这个预言是对的，只是时间上有偏差。
站在2022年的角度回头看，其实Java有很多明显的问题。 应用程序可以部署为 Web 或本机，但都没有一点“本机”的感觉。 Web-deployed applets运行在自己的“沙箱”中，并集成到网页中，整个运行过程缓慢而呆滞。
HTML5 的兴起
虽然 Java 一直想弥合 Web 和桌面之间的鸿沟，但它本身也受到了 Web 的胁迫。 到2002年，很多公司开始将原来的桌面软件功能迁移到Web端。 与桌面软件相比，这些 Web 应用程序的构建、维护和部署确实要便宜得多，但代价是会牺牲用户体验。
也正是在这个时候，Java开始提倡“富互联网应用”的概念，希望能够区分好的Web应用和不好的Web应用。 但等到 2004 年 Google Maps 正式登场时，Java 的小把戏彻底破产了。 谷歌地图以惊人的结果为丰富的网络应用程序设定了基准，人们使用 HTML5。
我最近重新观看了 Bill Atkinson 第一次向 Apple 爱好者演示 MacPaint 的旧视频。 当他第一次通过鼠标用画笔工具画出图案时，现场一片“哇”和掌声。 这叫做开创性。 我第一次看到 Google Maps 时也有类似的感觉。 地图可以无缝缩放和平移到各个方向，完全没有拼接的痕迹。 这里使用的新技术称为 AJAX（异步 JavaScript 和 XML），Web 应用程序中的人们第一次可以无缝地向服务器后端发出请求。 现在这一切当然是理所当然的，但在 2004 年，开发人员需要绞尽脑汁隐藏那些令人作呕的框架或弹出窗口，并确保在不刷新整个页面的情况下可以从服务器加载新数据。
作为一名 Web 开发人员，我当然对无限的可能性着迷。 但是从桌面发展的角度来看，这个历史性的变化似乎对桌面没有任何影响，尤其是Java。
在HTML5之前，“跨平台”是指“跨Windows、Mac、Linux”，所以跨平台的范围还是在桌面范畴内。 当时我没有意识到，但现在我看到 HTML5 的登场是一个新的平台时代——它将成为客户端应用程序的客观标准； 更重要的是，Java 将不支持这个平台。 突然之间，WORA 理念中出现了一个空缺——除了最重要的平台：Web 浏览器之外，每个平台的 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 应用程序不能在 Web 浏览器中运行（只有 applet 可以）。
为了解决这个问题，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年左右的java用什么软件编写，之后基本没有新增。 找不到答案的时候偶尔会写一篇问题分析博文。 两年后，当我遇到类似的问题时，我在 Google 上找到的只是我两年前的博文……说真的，现在有没有气喘吁吁的 Swing 开发人员？ 感觉真的很糟糕。
重新定义“桌面应用”
在许多方面，Web 的兴起使“桌面应用程序”的概念更加清晰。 Java 最初的跨平台客户端开发愿景并未区分瘦客户端（主要与远程服务器交互）和本机完整桌面应用程序。 这不仅增加了理解难度，也让安全模型的设计有些无所适从。 Java 理解中的“平台”是计算机本身，因此使用笨拙的沙箱来限制可能造成安全威胁的 API 访问，例如访问文件系统。 这是Java所有安全漏洞的根源，也是Java被逐出浏览器世界的原因。
这种基于“沙盒”的开发体验是相当糟糕的java用什么软件编写，因为很容易不小心“越界”而引发安全异常。 最终结果是几乎所有客户端都会请求对系统进行“可信”访问，从而完全绕过沙箱限制。
相比之下，HTML5 在网络和桌面之间建立了明确的界限。 默认情况下，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 的流行程度、深远影响，以及 Java 在 2011 年引领 Mac App Store 的其他趋势。不要小看 Mac App Store，它的出现堪称“ Java for Mac 桌面开发生态系统的斩首行动”。
（有兴趣的朋友可以多多留言，InfoQ会根据大家的需求不断翻译系列文章供读者阅读）
原文链接：
今日好文推荐
活动推荐
今年6月10日-11日，GMTC全球大前端技术大会将再次登陆北京。 其中“移动端性能与效率优化”专题，邀请了阿里巴巴无线开发专家储龙江先生（大银）现场分享，想了解阿里巴巴是如何做在线稳定性监控和客户端运维的对于1亿用户规模的应用？ 点击底部【阅读原文】查看更多。
会议门票20%优惠中，团体学习还有更多优惠~ 联系票务经理：+86 13269078023（微信同号）
单击以查看更少的错误
