曾经是“杀手级”桌面语言，Java 桌面开发为何走向衰落？

| 2022-03-08

图0: undefined曾经是“杀手级”桌面语言，Java 桌面开发为何走向衰落？

Java 不适合编写桌面应用，这是事实还是偏见？

本文作者以个人视角对 Java 桌面发展历程做了回顾，内容来自他在上世纪九十年代后期担任 Java 开发者时的所见所感，主要讲述曾经的“杀手级”桌面语言 Java 是为何从 21 世纪开始颓势尽显、步入衰落的。值得一提的是，作者如今在做一款开发者友好型 Java 桌面部署工具（jDeploy），其实他还是希望 Java 可以重拾风采，再度变得对桌面开发具有吸引力。

我的大学时代正好赶上 2000 年之前的最后那几年，当时 Java 是计算科学专业里的官方语言。虽然也有几门课程要求使用 C 和 C++，但所有基础知识教学都是围绕 Java 语言来设计的。为了防止有读者朋友较真，我再说得更准确些：这些课程会用 Java 语言来教学，不是说只教 Java。

其实大学的计算机科学课并不教授特定的编程语言，教学内容主要是相关概念，再使用时下流行的编程语言来演示这些概念，所以学生们得拿出课余时间掌握编程语言。也有些课程要求更严格，比如“这份作业必须使用 Java 完成”，但大多数高级课程就不再做此限制，大家想用什么语言就用什么语言。（有些作业需要使用特定的库或者编程语言。我还记得有一份作业就是用 pthreads 库为操作系统分配线程，相当于强制使用 C 语言。）

我上大学那会，对 Java 的认知还仅限于 Applet。我既不清楚 Java 在行业里是什么地位，也不知道它跟其他编程语言相比到底有什么优势。而且越是深入学习，我就越觉得 Java 这东西有点名不副实——它更像是种玩具语言，毕竟那些“真正”的严肃开发都是用 C++这类语言实现的。反正系里总有一帮故作深沉、头发胡子一大把的家伙，总爱吹嘘跟 C++一比、Java 屁都不是。

Java 很慢

他们倒也不是胡搅蛮缠，最常见的理由就是“Java 很慢”。相信任何用过 Java GUI 应用程序或者包含 Java Applet 网页的朋友都同意这个观点。那时候用 Java 编写的桌面应用程序就只有开发工具，我能想起的就是 ArgoUML 和 NetBeans，它们确实不好用而且速度很慢。那种慢，就像是双脚陷进了泥潭——无论是上下滚动还是打开菜单，所有操作都有“粘粘”的延迟。

但支持 Java 的教授们则坚持认为，只要配合即时编译，Java 也是可以快起来的。而且在编译了代码路径之后，“理论上”它的运行速度可以追平甚至超越 C++。但我们这帮学生根本不买账，单纯觉得他们是在嘴硬。

Java 应用程序不是“真正的”应用程序

另一个让人感觉 Java“不上档次”的原因，在于我们开发的应用程序都不是本机应用程序。Java 构建的应用程序只是一堆.class 文件的集合；哪怕再“高阶”一点，生成的.jar 文件也只能在安装了 Java 的计算机上运行。相比之下，其他学校的朋友们展示的项目就洋气多了，这些可是货真价实的可执行文件——双击之后，它们就像真正的专业应用程序那样开跑，有程序容器、也有屏幕顶端菜单，这才像话嘛。

我记得自己问过一位教授关于 Java 能不能生成本机可执行文件，他的回答是“为什么非得这样？生成本机可执行文件，Java 的跨平台优势不就没了吗？”

如果真的想把应用程序部署成桌面程序，他建议我研究研究 Java WebStart。这样不用本机程序包，Mac 和 Windows 用户也能顺利安装我的应用程序。WebStart 听起来挺有搞头，但我还是觉得跟自己的真正目标不太相符。毕竟就算可以用 WebStart 分发应用程序，用户也仍然需要事先安装 Java。我承认，当时已经是 2001 年，大多数计算机都预装了 Java。但跟直接双击就能打开，这种体验仍然不够好。

另外，在亲自尝试了一些 WebStart 应用程序之后，我发现它的表现也就那样。应用程序的打开速度还是慢，因为启动后需要先下载更新；这些程序也没有被正确集成到操作系统当中。虽然 WebStart 也提供在桌面上为应用程序保存执行别名的功能，但效果不好。

我相信那时候肯定已经有第三方工具能把 Java 应用程序成本机可执行文件，但不光会占用大量资源、而且绝对“只支持 Windows”。我也关注过 GCJ，这款 Java GNU 编译器宣称能把 Java 编译成机器码。但它只适用于 API 子集而且不支持 Swing——所以用户就只有两个选项，要么使用本机 GUI 工具包、要么干脆不要 GUI。

所以我心里有了答案：至少在当时，Java 桌面开发已经是死路一条，唯一的用处就是写点小程序——问题是跟 Flash 这类更轻、更快的技术相比，Java Applet 的优势其实也已经不明显了。

Applets：杀手级应用

虽然我这份“编年史”没那么详尽，但要谈 Java 在桌面端的发展历程，杀手级应用 Applets 肯定是个绕不开的话题。

Applets 在 1995 年那会确实颇具开创性，它们首次让用户在网页之内看到了交互式的 2D 图形与动画。最初（Java 1.0 时代），Java 解释器是被内置在浏览器当中的；但不久之后，就改为通过插件调用系统中已经安装的 Java 运行时。

最早的小程序嵌入起来非常简单，直接把.jar 或者.class 文件上传到 Web 服务器、再向网页中添加<applet>标记就行。遗憾的是，这种便捷性很快就消失了。随着 Java 新版本的发布和 IE 浏览器的出现，嵌入小程序所需要的 HTML 代码越来越复杂，需要针对不同的浏览器和 Java 版本使用不同的标签。虽然<applet>标签号称可以在“多浏览器”环境下正常嵌入小程序，但 IE 上实际使用的却是<object>标签，而 Mozilla 上使用的则是<embed>标签。

于是之前的嵌入方法

<APPLET code="MyAppletClass.class" archive="Applet.jar, EJB.jar" width="600" height="500" >
</APPLET>

就慢慢变成了：

<OBJECT classid="clsid: 8AD9C840-044E-11D1-B3E9-00805F499D93"
width="600" height="500">
<PARAM NAME=CODE VALUE=MyAppletClass.class>
<PARAM NAME="archive" VALUE='Applet.jar, EJB.jar'>
<PARAM TYPE="application/x-java-applet;version=1.5.0">
<PARAM NAME="scriptable" VALUE="false">
<PARAM NAME="cache-option" VALUE="Plugin">
<PARAM NAME="cache-archive" VALUE="Applet.jar, EJB.jar">
<COMMENT>
<EMBED type="application/x-java-applet;version=1.5.0" CODE=MyAppletClass.class
ARCHIVE="Applet.jar, EJB.jar" WIDTH="600" HEIGHT="500"
scriptable="false">
<NOEMBED>
</COMMENT>
</NOEMBED>WebSphere Java Application/Applet Thin Client for
Windows is required.
</EMBED>
</OBJECT>

如果系统上还没安装 Java，那情况就复杂了，几乎没有比较体面的处理方法。因为嵌入代码是由 NetBeans 生成的，所以小程序的构建过程相当复杂、需要由 JavaScript 检测系统中是否安装有 Java。如果没有，则提供指向 Sun 网站的 Java 下载链接。

直到 Java 1.3 版本，小程序的用户体验都非常糟糕，以至于 Applet 只能在系统管理员完全可控的客户端软件环境中才能使用。于是乎，靠 Java Applet 在网页中添加简单交互的计划基本破产。

时间快进到 2001 年，小程序的生命基本走到了终点。Flash 凭借着更简、更轻便、更快捷，取代 Java Applet 成为浏览器媒体交互的业界标准，也获得了更广泛的安装基础（我记得当时 99%的计算机都安装了 Flash）。

不止如此，小程序还大大败坏了 Java 的名声，其中很多安全漏洞都被宣传成“Java 漏洞”。这就给人留下一种错误印象，即任何用 Java 编写的东西都是潜在的安全威胁——虽然实际上这些“漏洞”只是小程序自己的问题。尽管之后很多年仍时不时能看到 Java 小程序的身影，但它在人们心中早已成了过时技术的代名词。

我一直觉得 Applets 算不上可行的桌面应用程序发布方式，但它能经久不衰、肯定也有自己的独到之处。

GUI 工具包：AWT、Swing 与 SWT

我刚开始使用 Java 那会，它的初始 GUI 工具包 AWT(Abstract Windowing Toolkit)已经有点过时了，倒是新的“轻量级”工具包 Swing 得到了人们的青睐。简单来讲，AWT 属于“重量级”工具包，提供的是用于处理本机小部件的 API。重量级 UI 库的问题在于难以维护，而且受到底层平台可用组件的限制。相比之下，Swing 则拥有轻量化优势，能够绘制自己的一组小部件、降低了维护难度，帮助用户轻松绘制出自己的跨平台界面。

Swing 提供可插入 UI，支持样式设置以模拟本机平台的外观。所以在 Mac 上运行时，Swing UI 的观感与 Cocoa 等本机应用程序完全相同；而在 Windows 上运行时，观感又高度接近 Windows。此外，Swing 还允许自定义外观，让程序的使用体验脱离任何操作系统平台。总之，这是一款灵活的 UI 解决方案。

但在 2000 年初的计算机上，Swing 界面也是出了名的资源杀手。我自己有一台半透明蓝色的 iMac，它搭载的 233 MHz 芯片几乎运行不了 NetBeans。我爸爸的 G4 电脑搭载 400 MHz 处理器，性能倒是更强一些，但整个运行体验仍然勉勉强强、凑凑合合。

所以在当时，用 Java 构建 GUI 要求人们对摩尔定律抱有极大的信心——虽然当下的运行表现不好，但再过几年应该会有起色。

时间来到 2002 年，一天室友向我推荐了 Eclipse 与 SWT——这是一套似乎能够解决性能问题的 Java GUI 开发替代方案。Eclipse 使用的是 SWT（Standard Widget Toolkit），一款新的“重量级”Java UI 工具包，但响应速度明显要比使用 Swing 进行构建的 NetBeans 更快。所以乍看之下，长久的难题似乎终于有了答案。

SWT 的优势在于无需自行绘制小部件，而仅仅是为了平台的本机小部件提供绑定，因此由它构建的应用程序在观感上原生度更高、响应速度也更快。但经历过 AWT 的糟糕体验，我仍然保持着警惕。既然 Sun 公司的聪明人都觉得轻量化才是正确的道路，为什么 IBM 这边拿出的是重量级工具包呢？

而且我对 SWT 的兴奋也没持续多久。Eclipse 虽然比 NetBeans 响应更快，但用起来仍然有种笨拙的感觉，完全达不到本机应用的水平。倒是 Swing，虽然速度还是更慢，但一直随着新版本的发布而不断改善。根据 AWT 与 Swing 相关书籍、论坛和博文的数量，我估计 Swing 社区的规模比 SWT 大得多。Swing/AWT 曾经是、现在也仍然是 Java 中内置的唯一工具包，能够确保开发者无需任何第三方依赖项、单凭 Java 运行时环境就构建起完整的 GUI 应用程序。

虽然我还没有在项目中实际使用过 SWT，但很高兴看到它能经受住这么多年的风雨考验。期间先后出现过不少不支持 Swing 的 JVM（Avian 就是其中一种精简型 AOT（预先）编译器，它不支持 Swing、但提供使用 SWT 的 GUI 演示），靠的就是 SWT 这个能在 Java 平台上快速编写 GUI 应用程序的解决方案。

据我所知，2000 年初那会的跨平台 Java GUI 开发市场就是由 AWT、Swing 和 SWT 这三家主导。Java FX 直到 2007 年才出现。

Java Cocoa 应用

还是在 2000 年初，苹果突然宣布要把 Java 作为 Mac OS X 上的首选编程语言。Java 被预装在 OS X 当中，Swing 也获得了本机 Mac 主题，使其观感高度接近于本机应用程序。这意味着大家完全可以将 Java 应用程序直接发布给 Mac 用户，代码一定能在机器上运行起来、而且提供与本机系统相匹配的观感体验。

他们还推出能将 Java 应用程序打包成本机 OS X.app 的工具，所以开发者就能把 Java 应用程序像真正的本机应用那样交付给用户。如果认真遵循 Mac 用户界面指南，使用者甚至感受不到这款应用程序是用 Java 编写的。

遗憾的是，大多数 Swing 应用程序的开发者并没有遵循 Mac UI 指南，所以用户在使用 Java 应用程序还是能感觉到事情“不太对劲”。比如应用程序可能在菜单项中使用了错误的加速键、甚至不提供标准菜单。没错，虽然听起来很简单，但想让 Swing UI 在 Mac 上完全适配本机风格还是颇有难度。这里我们用 Mac UI 的本机工具包 Cocoa 来对比：Cocoa 提供的是完全原生的应用程序外壳，并且以菜单为起点；但 Swing 应用程序则是从零开始。开发者必须自行创建窗口和菜单，除非直接套用框架——但我从没见过能纯原生 Mac 应用程序体验的 Java 框架。

但苹果总有办法，他们更进一步、为 Coca 提供了 Java 绑定包。如此一来，我们的 Java 应用程序不仅看起来更像是本机应用程序，实际上也成了本机应用程序。我们只需要在 Xcode 中创建一个新的 Cocoa 项目，再选择 Java 作为项目语言即可。它会为大家提供漂亮的本机应用程序外壳作为设计起点，而在按下“Build”键时，生成的将是一个可以直接发送给用户的纯本机应用程序。

我也用 Cocoa 试着编写过示例应用程序，效果非常完美。但即便表现出色，它在行业中也仍然不受待见。因为这类应用程序只适用于 Mac，毕竟用的是 Mac 上的专有 UI，所以 Java 社区里“一次编写、随处运行（WORA）”的狂热支持者们对 Cocoa 嗤之以鼻。另一方面，“原生”Mac 开发社区则对 Java 不感兴趣，所以相关文档很少。而且要实现从 Cocoa 到 Java 的对接，开发者必须能熟练地将 Objective-C 代码转换成 Java 中的等价表示——相当累人。

所以不出所料，苹果在几年之后的 2005 年就放弃了 Cocoa-Java 项目。而且出于种种原因，苹果对 Java 的兴趣也很快淡去。我记得当时史蒂夫·乔布斯还有句名言，“Java 如同开发者的镣铐”。他说得一点儿没错。

如果大家也想试试用 Java 编写 Cocoa 应用程序，请关注Rococoa项目。作为 Cocoa-Java 理想的继任者，它目前仍处于活跃状态。

这让我们何去何从

我的这份“编年史”既不全面、也不完全遵照时间顺序。我讲述的是自己在 Java 桌面环境上的真实经历，而且主要偏向 Mac 一侧（因为家里的第一台计算机是苹果 IIGS，我爸后来又买了台 Mac Classic）。

所以结合个人经历，2005 年可以说是 Java 语言在桌面环境中的发展转折点。在 2005 年之前，网络论坛上有着大量关于 Java 桌面技术的问答内容，例如 Swing、Cocoa Bridge 等。但到 2005 年之后，相关内容快速减少。那 2005 年前后到底发生了什么重大转变？Java 桌面开发者们又跑到哪里去了？我猜大部分开发者可能转向了服务器端，而继续坚守客户端的开发者也许是转向了 Web 或者本地开发方面。

如果您也经历过这段历史，不妨在评论中聊聊自己的体会和回忆。也许拥有不同背景、不同职业生涯的开发者会有不一样的观察角度。

原文链接：

https://jdeploy.substack.com/p/the-decline-and-fall-of-java-on-the?s=r

本文文字及图片出自 InfoQ