【QCon】精华内容上线92%,全面覆盖“人工智能+”的典型案例!>>> 了解详情
写点什么

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

  • 2022-03-06
  • 本文字数:5385 字

    阅读完需:约 18 分钟

曾经是“杀手级”桌面语言,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.classARCHIVE="Applet.jar, EJB.jar" WIDTH="600" HEIGHT="500"scriptable="false"><NOEMBED></COMMENT></NOEMBED>WebSphere Java Application/Applet Thin Client forWindows 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

公众号推荐:

2024 年 1 月,InfoQ 研究中心重磅发布《大语言模型综合能力测评报告 2024》,揭示了 10 个大模型在语义理解、文学创作、知识问答等领域的卓越表现。ChatGPT-4、文心一言等领先模型在编程、逻辑推理等方面展现出惊人的进步,预示着大模型将在 2024 年迎来更广泛的应用和创新。关注公众号「AI 前线」,回复「大模型报告」免费获取电子版研究报告。

AI 前线公众号
2022-03-06 22:329252
用户头像
罗燕珊 InfoQ中文站编辑

发布了 413 篇内容, 共 238.6 次阅读, 收获喜欢 756 次。

关注

评论 6 条评论

发布
用户头像
微服务架构趋势下如何处理存量系统
https://xie.infoq.cn/article/3f9e2ea9e02ef60a90f7dac3d
2022-03-26 00:19
回复
用户头像
感觉java从来都没有成为桌面应用杀手。那时有delphi ,vs 下 有 vc vb
2022-03-10 10:52
回复
用户头像
移动互联网发展中后场,不仅仅是Java,基于其他语言工具的“桌面程序”也都逐步没落。
2022-03-07 11:25
回复
用户头像
主要是因为行业从c/s转向b/s了,以及移动互联网app的兴起,Android可以看作Java GUI的另外一种变种。跨平台的重桌面级应用场景不多了,IDE算是一个。当系统复杂度远远高于性能差异的时候,Java这种跨平台更简单的语言还是有用武之地的
2022-03-07 10:09
回复
UI的开发要想流行,其一是简单,其二是灵活,其三是跨平台,UI的底层关键是渲染,有更高效的渲染实现比较重要,Web是最灵活最容易最强大的UI,很多桌面方案,如果考虑多方面因素,可能选择Web还是最佳的选择
2022-03-07 10:18
回复
用户头像
等GraalVM支持Swing,SWT,JavaFX, 估计Java的桌面开发会迎来高峰.
2022-03-07 09:55
回复
没有更多了
发现更多内容

01. 你身边的AI

数据与智能

人工智能

OceanBase 源码解读(三)分区的一生

OceanBase 数据库

数据库 分布式数据库 oceanbase OceanBase 开源 OceanBase 社区版

网络安全小白别拜师了,求人不如求己

网络安全学海

黑客 网络安全 信息安全 渗透测试 安全漏洞

☕【Java技术指南】「OpenJDK专题」想不想编译属于你自己的JDK呢?(Windows10环境)

洛神灬殇

Java jdk Openjdk 8月日更

正经人一辈子都用不到的 JavaScript 方法总结 (二)

编程三昧

JavaScript 大前端 8月日更

🚀【Guava技术指南】「RateLimiter类」服务请求流控实现方案

洛神灬殇

Java ratelimiter Guava 8月日更

graphql中的'子查询'

杜艮魁

开源 后端 graphql

百度地图开发-实现离线地图功能 05

Andy阿辉

android 百度地图 Android 小菜鸟 Android端 8月日更

模块一作业

紫云

架构实战营

作业

Li. Mr

极客时间【架构实战营】第二期 模块一作业

Geek_91606e

架构实战营

搜索引擎渐行渐远,未来路在何方

石头IT视角

微信的业务架构图

Rabbit

架构实战营

HTTP协议之:HTTP/1.1和HTTP/2

程序那些事

HTTP 程序那些事 HTTP协议 http2

OpenJDK源码下载

4ye

源码 后端 JVM 8月日更

微信业务架构图-作业

Geek_a772a7

图像分类-cifar100 实验研究

毛显新

人工智能 神经网络 tensorflow 图像识别 keras

[架构实战营]模块一

Amy

架构实战营 业务架构图

在线JSON转XML工具

入门小站

工具

架构师实战营作业[模块一]

看,有只猪

学生管理系统(作业)

Geek_a772a7

微服务容错组件Hystrix设计分析

慕枫技术笔记

分布式 后端 熔断

【DPDK工程师手册】 —— 官方文档,最新视频,开源项目,论文,大厂内部ppt,知名工程师一览表

奔着腾讯去

Linux DPDK VPP

模块一作业

potti

架构实战营

AI巨头们建造的“新世界”,进展如何?

脑极体

Linux之nohup命令

入门小站

Linux

初识html,一文搞懂HTMl骨架标签都有哪些含义及浏览器内核

你好bk

html html5 大前端 浏览器 html/css

学习心得-架构训练营-第一课

Fm

架构训练营模块一作业

guangbao

架构实战营模块六作业

老猎人

架构实战营

架构训练营 模块一作业

初一

曾经是“杀手级”桌面语言,Java桌面开发为何走向衰落?_语言 & 开发_Jeffrey Burt_InfoQ精选文章